Hi Bert, I don't necessarily agree with the arguments but I do appreciate the thoughtful response, so thank you for that. In that case I think it would be helpful to call this out explicitly in the AUR submission guidelines (maybe with a link pointing to this discussion). So, unless you are planning to do that, I may go ahead and add a note mentioning this in the next couple of days. As for my "aarch64" packages, I guess I'll just need to find (or create) a different repository for them. On Tue, Nov 26, 2024 at 7:43 PM Bert Peters <bert@bertptrs.nl> wrote:
Hi,
On Mon, 2024-11-25 at 18:22 +0000, Valentin Hăloiu wrote:
Hello,
I have recently created an AUR package (uboot-cm3588-nas) that's only usable on the "aarch64" architecture (e.g.: Arch Linux ARM) which got promptly removed due to: "not for Arch Linux, aarch64 only package".
However, the AUR submission guidelines do not make it very clear whether non-x86_64 packages are allowed in the AUR or not.
The closest reference that I could find in relation to this is the Arch package guidelines - Architectures section which mentions:
The arch array should contain 'x86_64' if the compiled package is architecture-specific. Otherwise, use 'any' for architecture independent packages.
This makes it sound like only x86_64 packages are allowed but, to me, that still sounds like there is some room for interpretation.
So, my main question is: are packages for other architectures allowed in the AUR?
Also, in light of recent discussions around Arch Linux Ports, I think it would be helpful to spell out the answer to this question explicitly in the AUR submission guidelines.
As the person who accepted the deletion request in question, I feel I should comment on this.
This is a good question, and one to which the answer needs to be written down and consistently answered. My understanding of the policy, as it exists now, is based on this section of the submission guidelines [1]:
The AUR and official repositories are intended for packages which install general software and software-related content, including one or more of the following: executable(s); configuration file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.
The crux here is "for the Arch Linux distribution." Packages in the AUR should be useful on Arch Linux, which is currently an x86_64-only distribution. Software that doesn't work on that architecture, therefore shouldn't be in the AUR, as it is not for Arch Linux, even if it may be useful for Arch Linux derivatives.
That does not mean your PKGBUILD may not support other architectures. On the contrary. With the various ports out there, it makes sense to share the existing PKGBUILDS. There is nothing that prevents you from adding additional architecture support to your arch array, or even sources specifically for different architectures, as long as it also works for x86_64.
Arch Linux in my opinion not should be hosting arbitrary PKGBUILDs for any distro that might want to host user scripts somewhere. Requiring PKGBUILDs to be useful for Arch while allowing other architectures to be supported seems like a reasonable compromise.
As a final note, there is talk of eventually supporting more architectures for Arch Linux. Should that day come, the AUR may of course host PKGBUILDs for those architectures specifically. I do hope we get there.
Cheers,
Bert.
[1]: https://wiki.archlinux.org/title/AUR_submission_guidelines