[Slackbuilds-users] About aarch64 support support in TEMPLATE.info

[B. Watson]

On Tue, 15 Apr 2025, David Chmelik wrote:

> Is it possible to put DOWNLOAD_aarch64 & MD5SUM_aarch64 on-site

No, not any time soon, because it would require major database and
site surgery. My compromise from the last email is basically "allow
them in .info files but don't store them in the database".

It's also a simple code change, to one script, and doesn't require
any database changes at all. It's low-impact. In other words it's
something I could do *right now* if the other admins agree that it's a
good idea.

Doing the "full support" you're asking for would require a lot more
work, and probably would have to wait until a "development cycle"
(when a new Slackware gets released and our submissions are closed).
No idea when the next release will be... and, don't misread this
paragraph: I'm not saying "we will fully support aarch64 after the
next Slackware release". I'm saying "**IF** we decide to fully support
aarch64, it wouldn't happen until the next Slackware release".

> but not officially test build until enough team members are involved?

What would be needed for "official test builds" would be a CI
system that can be triggered by git commits, like we have for x86
and x86_64. I'm not sure how involved that would be, but it would
at minimum require buying a fast aarch64 server (if such a thing
exists). Emulating aarch64 on x86_64 is just too slow to be practical.

Note that the .info file stuff really only matters for builds that are
binary repacks. When building from source, normally the same source
works on x86, x86_64, and aarch64.

> Often I search website for download URLs, though I only have two
> older Raspberry Pi (RPi) Slackware servers, I'm reorganizing---not
> currently using--but maybe this or next decade I'll have a Slackware
> ARM laptop.

OK, you'd have one extra click (click on the .info file on the build
page). Depending on your browser, you might have to copy/paste the
aarch64 URL, or the browser might helpfully present it as a link (even
though .info files are plain text, not HTML).

> On that topic, sbopkg should be on website, because sbotools, etc., are, 
> and the rest can self-update from it, so sbopkg should, especially since 
> sbopkg isn't truly 'third-party' for some years rather than being 
> maintained by a SlackBuilds.org team member.

sbopkg is maintained by an individual SBo team member, with occasional
contributions from other SBo team members, and from people who aren't
on the SBo team.

sbopkg isn't required, to use SBo. One reason it's third-party is that
multiple tools exist (sbopkg, sbotools, sborepo) and we don't want to
support (read: *endorse*) one but not the others (and we don't want to
support all of them).

It's also third-party partly because the rest of the SBo team is *not*
interested in being responsible for it. Right now, if you say to me
"thus and such doesn't work in sbopkg", I can decide I'm too busy to
deal with sbopkg issues (because they're not SBo issues), and point
you towards the *separate* maintainer, mailing list, github repo, LQ
threads, etc.

I know that makes me sound horrible, or horribly lazy, but life
is short and I already have 900+ SlackBuilds to maintain, plus the
sbo-maintainer-tools, plus the SBo source archive... and a real life
outside the SBo world.