On Tuesday, November 28th, 2023 at 3:21 AM, Lockywolf <for_slackbuilds-users_mlist_2023-04...@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@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@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
