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 <b...@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 >
