ngl I don’t really understand why the AUR takes such a hard-line stance against like WSL2-specific (especially since you can install plain Arch in WSL2 via the official bootstrap tar.zst releases) and now ARM-specific packages. it’s… entirely user maintained. it’s not like it’s extra workload on Arch maintainers, I think?
feel free to correct me or explain it, I’m just confused.
I guess they’re trying to play extra safe until the new rules for new arches, which as discussed on a RFC will change the Arch stance on arches different than x86-64. In the end, even if it’s a very small cost (economic and time wise), you’re using the resources of a distro for something that is not supported by them. Arch Linux ARM is a different project right now. Just like Ubuntu and Debian are different projects, although one is based on the another.
Since the cited examples rejected are all of software that does not make sense to install on amd64, not really? I think your argument would more support a position of “if this software can be built for amd64, you need to support that”.
Keep in mind that AUR is, from the point of view of Arch Linux, unofficial and not part of the Arch Linux distro. Also note that Arch Linux ARM is an excellent, but separate, project. Arch Linux may support more architecures in the future, though.
Sure, if you don’t mind your mainline kernel not being updated for half a year at a time with no communication whatsoever and no way to actually change anything about this. Also no way to report bugs, except scream into a phpBB2 forum.
ALARM is in fact so bad, Asahi moved away from it and publicly blasted it for how dead it is.
Arch Linux ARM has always worked fine when I’ve tried it, but these are all fair points.
My main message though, for people that might not be aware of it, is that Arch Linux ARM is a separate distro from Arch Linux. And AUR is also separate.
The packages on AUR are not official packages. They are not enabled or made available in Arch Linux by default. Users will have to actively choose to use packages from AUR.
AUR is not part of the Arch Linux distribution. For example, it does not come with the ISO file that users can download when they choose to download and install Arch Linux.
aur.archlinux.org and archlinux.org share the same domain, and there is some overlap of people working on both, but they are different projects / sub-projects.
There are arguments both for and against AUR also supporting other architectures than x86_64:
Arch Linux is x86_64 only. AUR had Arch Linux in mind when it was started, so it makes sense if they support the same architectures as Arch Linux supports.
If someone wants AUR to support more architectures, they can create their own AUR software that supports this. Heck, since aurweb is open source, they can just deploy it to a new server.
Managing all the AUR packages is a lot of volunteer work. It is understandable if only some architectures are supported.
aarch64, RISC-V and friends are the future, so both Arch Linux and AUR should move to support them. AUR should lead the way by supporting multiple architectures first.
Arch Linux ARM, being a separate distro from Arch Linux, should set up their own AUR instance for all the architectures that they wish to support.
(I’m not neccessarily for or against any of these points, I just tried to list all the pros and cons I could think of).
If someone wants AUR to support more architectures, they can create their own AUR software that supports this. Heck, since aurweb is open source, they can just deploy it to a new server.
This one has at least two follow up points too.
AUR helpers (which, whether you like it or not, is how most users consume PKGBUILDs from AUR) could be patched to swap AUR instance endpoint, or support two AURs alltogether.
The latter would create further complexity inside the dependency resolving module. [1]
and also
it might be pertinent to accept that aurweb is de facto a code forge, just highly specialized.
[1] compare and contrast to the drama around the hardcoded flake registry inside nix.
Keep in mind that AUR is, from the point of view of Arch Linux, unofficial and not part of the Arch Linux distro.
Exactly, why then AUR maintainers have decided to gate keep out packages that soon will be there anyway? IMHO the optics of removals are terrible. It just creates friction to the soon to be your users, comes as prideful, and frankly bit disrespectful.
It’s even more surprising because usually Arch as whole is on point and avoid visible drama.
Most AUR packages are just a PKGBUILD file, but the point of AUR is to host PKGBUILD files. Elsewhere, just means somewhere harder to find, and while installing a local PKGBUILD is trivial, an AUR helper helps with keeping all AUR packages up to date (vs having to hunt for each PKGBUILD individually to see if a new version came out).
ngl I don’t really understand why the AUR takes such a hard-line stance against like WSL2-specific (especially since you can install plain Arch in WSL2 via the official bootstrap tar.zst releases) and now ARM-specific packages. it’s… entirely user maintained. it’s not like it’s extra workload on Arch maintainers, I think?
feel free to correct me or explain it, I’m just confused.
I guess they’re trying to play extra safe until the new rules for new arches, which as discussed on a RFC will change the Arch stance on arches different than x86-64. In the end, even if it’s a very small cost (economic and time wise), you’re using the resources of a distro for something that is not supported by them. Arch Linux ARM is a different project right now. Just like Ubuntu and Debian are different projects, although one is based on the another.
at least as long as arch is an amd64-only distro, do you not think there is value in being able to install any package listed on the AUR?
Since the cited examples rejected are all of software that does not make sense to install on amd64, not really? I think your argument would more support a position of “if this software can be built for amd64, you need to support that”.
i’m saying as long as arch is amd64-only, it doesn’t make sense to list packages which don’t make sense to install on amd64
iow, the
archfield should ideally be useless as of now, kept only for a hypothetical future - the only other “arch” isanywhich is used for scriptsKeep in mind that AUR is, from the point of view of Arch Linux, unofficial and not part of the Arch Linux distro. Also note that Arch Linux ARM is an excellent, but separate, project. Arch Linux may support more architecures in the future, though.
Sure, if you don’t mind your mainline kernel not being updated for half a year at a time with no communication whatsoever and no way to actually change anything about this. Also no way to report bugs, except scream into a phpBB2 forum.
ALARM is in fact so bad, Asahi moved away from it and publicly blasted it for how dead it is.
Arch Linux ARM has always worked fine when I’ve tried it, but these are all fair points.
My main message though, for people that might not be aware of it, is that Arch Linux ARM is a separate distro from Arch Linux. And AUR is also separate.
Unless I’m missing something terribly obvious, it’s false.
It is true, but I could be more specific:
The footer of the aur.archlinux.org says:
While the footer of the archlinux.org page says:
Oh, I’ve read it as “ALARM has their own separate A(LARM)UR”.
But then the fact that AUR is separate from the Arch proper should be even further argument against removing ARM-only PKGBUILDs.
There are arguments both for and against AUR also supporting other architectures than
x86_64:x86_64only. AUR had Arch Linux in mind when it was started, so it makes sense if they support the same architectures as Arch Linux supports.aarch64,RISC-Vand friends are the future, so both Arch Linux and AUR should move to support them. AUR should lead the way by supporting multiple architectures first.(I’m not neccessarily for or against any of these points, I just tried to list all the pros and cons I could think of).
This one has at least two follow up points too.
and also
[1] compare and contrast to the drama around the hardcoded flake registry inside nix.
Exactly, why then AUR maintainers have decided to gate keep out packages that soon will be there anyway? IMHO the optics of removals are terrible. It just creates friction to the soon to be your users, comes as prideful, and frankly bit disrespectful.
It’s even more surprising because usually Arch as whole is on point and avoid visible drama.
I understand the surprise here, but I’m not sure it’s actually a problem? For
fex-emufor example, AUR was really just hosting aPKGBUILDfile* which could just as easily be hosted elsewhere - perhaps even the ArchLinuxARM repositories.Arch is very clear that if you’re using the AUR, you should know how to obtain and build from a
PKGBUILDfile even if you’re using a helper. And all the helpers I know can install from a localPKGBUILDeasily.*
.SRCINFOis also there, but generated fromPKGBUILD.Most AUR packages are just a PKGBUILD file, but the point of AUR is to host PKGBUILD files. Elsewhere, just means somewhere harder to find, and while installing a local PKGBUILD is trivial, an AUR helper helps with keeping all AUR packages up to date (vs having to hunt for each PKGBUILD individually to see if a new version came out).
This comes a few months after the Arch Linux Ports RFC being approved/merged.
It seems they’re having trouble progressing in terms of multi-architecture support.
This is going to be increasingly important as RISC-V user base grows.