>> 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".
That line currently means that the package does not build on ix86.
The DOWNLOAD_X86 line would effectively break backward compatibility.
But adding optional DOWNLOAD_{ARCH} for ARCH in ARM and AARCH64, and maybe
later RISCV who knows, alongside the existing X86_64, looks like a fully
backward-compatible evolution.
And not very hard to use in existing tools, and easy to understand for
maintainers, and users also.
So I am fully in favor of that evolution : allowing DOWNLOAD_{ARCH} for other
values, with the corresponding MD5SUM_{ARCH}. I already use it at home for
syncthing on arm and aarch64.
As for names, I'm unsure, but yeah, there are some problems with downloaded
files, depending on tool, content-disposition, source also, etc.
--
Yth._______________________________________________
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/
