[Slackbuilds-users] [RFC] Adding features to .info format.

[Vladimir Nikishkin]

Erich Ritz via SlackBuilds-users <slackbuilds-users at slackbuilds.org> writes:

> On Tuesday, November 28th, 2023 at 3:21 AM, Lockywolf <for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net> wrote:
>
>
>> 
>> 
>> Hello, colleagues
>> 
>> There have been repeated discussions about two features that the current
>> .info file format is missing:
>> 
>> 1. aarch64 architecture. If in the past slarm64 was still an unofficial
>> port, with -current it is official, and quite widely available, given
>> the number of RPi machines available.
>> 
>> 2. urls of the form https://example.test/address/ and
>> https://example.test/address/1.json , which are either not supported
>> by wget or can be mixed with each other, if downloaded into the same
>> directory, which is especially bad with Golang and Haskell builds,
>> which have many package-components, called 1.json.
>> 
>> To address this issue, I propose a backward-compatible change to .info
>> files format.
>> 
>> 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated
>> bash-string-list, identical in function to DOWNLOAD and
>> DOWNLOAD_X86_64
>
> I think you mean DOWNLOAD_AARCH64 and DOWNLOAD_X86 function like DOWNLOAD_X86_64: they override DOWNLOAD for their respective arch.  DOWNLOAD retains its current meaning.
>
> My first thought was DOWNLOAD_X86 is not needed because the same end result can be
> achieved with DOWNLOAD, DOWNLOAD_X86_64, and DOWNLOAD_AARCH64. But now I think I
> agree with you because it has a different meaning: DOWNLOAD is a (mostly)
> arch-independent download, where 1 or more of DOWNLOAD_* may be needed to override
> it. However, the absence of DOWNLOAD and the use of DOWNLOAD_* communicates that
> there are no arch-agnostic downloads; every download tarball is arch-specific.
>

Sorry, _almost_ like this, but not quite. To maintain current behaviour,
the absence of arch-agnostic downloads is indicated by
DOWNLOAD="UNSUPPORTED".

>> 
>> 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and
>> DOWNLOAD_X86_NAME, space-separated optional strings, which, if
>> present, specify what the results of download should be named. If
>> they are absent, current logic is not changed.
>
> Similarly, DOWNLOAD_NAME is arch-agnostic, while DOWNLOAD_X86_NAME, DOWNLOAD_X86_64_NAME, and DOWNLOAD_AARCH64_NAME provide overrides for their respective arch.
>

Yes.

>> 
>> Please, consider the upsides and downsides of this RFC.
>
> If this RFC is implemented, future changes could support DOWNLOAD_${ARCH} and DOWNLOAD_${ARCH}_NAME.
>
> By the way, I'm not explicitly supporting or NAKing this proposal.  I'm just trying to help clarify the meaning of the new names.
>
> Erich
>
>> 
>> --
>> Your sincerely,
>> Vladimir Nikishkin (MiEr, lockywolf)
>> (Laptop)
>> _______________________________________________
>> SlackBuilds-users mailing list
>> SlackBuilds-users at slackbuilds.org
>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - https://slackbuilds.org/faq/
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/


-- 
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)