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

[Erich Ritz]

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.

> 
> 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.

> 
> 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/