[Slackbuilds-users] using $DOWNLOAD for alt. purpose

[Arnaud]

> > So I've got a few scripts that are 64bit only and have different binary 
> > files to download for amd64 or aarch64. The scripts are setup to fail on 
> > 32bit and I'd like to know if it'd be possible for me to use the 
> > $DOWNLOAD for the aarch64 files, so I don't have to omit a otherwise 
> > working script for the platform I mostly use.
> > 
> > As-is this works with the tool "sboui" on my machines and automatically 
> > gets the $DOWNLOAD on aarch64 and the correct one on x86_64 as well.
> > 
> > Would it be acceptable to have the script itself fail on 32bit rather 
> > than marking $DOWNLOAD=unsupported so we can offer support for the 
> > aarch64 platform?
> > 
> > Side note: is there any future plans to add a $DOWNLOAD_AARCH64 to the 
> > .info?
> 
> As far as i can tell, no
> Not all admins have access to ARM machines to test the script, so the 
> best thing we can do is to offer parameter  flags for ARM architecture.
> 
> https://git.slackbuilds.org/templates/commit/?id=20ac57b04874a38a4a1b4aa8d0fa4ec95a5605a4
> 
> https://slackbuilds.org/faq/#ports
> 
> -- 
> Willy Sudiarto Raharjo
> 

My own 2¢ about that :
I, personally, only needs an ARM/AARCH64 source for syncthing.
On those boxes, I patch the .info to setup the ARM or AARCH64 source, it works
only for me and myself.

If we had optional DOWNLOAD_ARM/MD5SUM_ARM and DOWNLOAD_AARCH64/MD5SUM_AARCH64,
build tools could be updated to use them if present, or simply ignore them if
they wouldn't want to handle ARM in any way.
The download links would be there for any purpose.

This seems - to me - the least intrusive solution, with a clean design.
I truly dislike the idea of repurposing an UNSUPPORTED DOWNLOAD value for ARM
purposes, it would be very unclear.

Of course, the problem of having an ARM/AARCH64 DOWNLOAD link while not
supporting it is present. But that wouldn't be for all .info files, probably
very few of them, as the vast majority have a unified DOWNLOAD for sources that
works everywhere, even ARM or AARCH64.

That might be a simple step to allow some unsupported support of those
architectures.

 - Yth.