First step for non-x86_64 contributions
# First step for non-x86_64 contributions Hey everyone, I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes. There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules. We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/). ## Guidelines ### Protecting x86_64 We do not want to compromise on our primary platform. Clearly do not break or remove x86_64 behavior, functionality or features. Incompatible features or dependencies must be proposed in a way that preserves the functionality of our primary platform. ### Non-intrusive Small, focused changes that are easy to understand at a glance and can be reasoned about even without building and running it on different architectures. ### No downstream wizardry Complex, opaque, or heavy software patching is out of scope. Carrying around massive software patches downstream isn't feasible at this stage, save that for later and work together with upstream instead. ### Merge-request indicator All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others. ### Manageable load Contributors must stick to small merge-request batches max 10 open MRs per person. All proposals must be sent manually, no fire-and-forget scripts. Collaboration is expected. If questions come up, we expect thoughtful responses from people who precisely know the changes they're submitting. ## Out of scope ### arch array No changes to `arch=()` arrays. ### non-x86_64 issues No issues or bug reports for non-x86_64. If something's broken with the `PKGBUILD`, you'll need to sort it out and send a merge-request. Don't file bugs in the tracker for other architectures. --- This approach allows us to slowly build up compatibility and make good progress without burning out our packagers and bug-wranglers or flooding our GitLab with changes and bug reports we can't handle. We can stretch out the work by allowing confined changes and avoid to stack it all for later. It gives us room to prepare without needing full build infrastructure, provide active support or require special hardware in place today. I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community. Cheers, Levente
Hey Levente, On 2025-07-01 17:57:37 (+0200), Levente Polyak wrote:
There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules.
We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/).
I agree!
### Merge-request indicator
All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others.
Externals usually do not have the right to set a label on a merge request (I might be wrong here). To clarify: The bug wranglers/package maintainers should add this label, right?
I think this really hits the right balance, tight enough to avoid burnout, open enough to make progress and welcoming enough to motivate and start harvesting work from our community.
I'd obviously be happy to see this happen! If people in the team are generally fine with this, I think we should also create a dedicated news entry. Best, David -- https://sleepmap.de
On 7/1/25 6:44 PM, David Runge wrote:
### Merge-request indicator
All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others.
Externals usually do not have the right to set a label on a merge request (I might be wrong here). To clarify: The bug wranglers/package maintainers should add this label, right?
I'd probably want to spend a bit of time looking into merge-request template with some check-boxes, we already have experience rolling it out for a whole group in the buildbtw sandbox. With a dedicated template we have all the required markers for bugbuddy to identify such a merge-request and add the label automatically. As a fallback, if contributors aren't following the appropriate procedure, bug wranglers/package maintainers would need to fix the label. Cheers, Levente
On 2025-07-01 18:56:05 (+0200), Levente Polyak wrote:
On 7/1/25 6:44 PM, David Runge wrote:
### Merge-request indicator
All secondary architecture related merge-requests must be flagged with the new `pkg::ports` GitLab label. It'll help separate them from the usual requests and allow interested packagers and contributors to filter on them globally, to help out others.
Externals usually do not have the right to set a label on a merge request (I might be wrong here). To clarify: The bug wranglers/package maintainers should add this label, right?
I'd probably want to spend a bit of time looking into merge-request template with some check-boxes, we already have experience rolling it out for a whole group in the buildbtw sandbox. With a dedicated template we have all the required markers for bugbuddy to identify such a merge-request and add the label automatically. As a fallback, if contributors aren't following the appropriate procedure, bug wranglers/package maintainers would need to fix the label.
Right, that sounds like a sensible solution and thanks for clarifying! Best, David -- https://sleepmap.de
On Tue, 1 Jul 2025 17:57:37 +0200 Levente Polyak <anthraxx@archlinux.org> said:
# First step for non-x86_64 contributions
Hey everyone,
I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes.
There's already a ton of community interest and effort around non-x86_64. There's plenty of low hanging fruits and clean patches that are easy to review, well contained, and good groundwork. So instead of waiting for the perfect day before starting, I'd like to open the door to small, clear, and non intrusive contributions under tightly scoped rules.
We should rather slowly and carefully build up compatibility now, than scramble once infra, hardware and tooling catches up. I propose the following guidelines as a first step towards implementing [RFC0032](https://rfc.archlinux.page/0032-arch-linux-ports/).
Oh... This warms the frozen depths of my ice-bound heart. :) \o/ Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - raster@rasterman.com
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
On 7/1/25 5:57 PM, Levente Polyak wrote:
# First step for non-x86_64 contributions
Hey everyone,
I'd like to share my view on the first step for targeting non-x86_64 architectures in our packages. While our official infrastructure for non-x86 support isn't ready yet and will still take some time to materialize, I'd very much like to avoid siting on our hands until that day comes.
Very good news! I'm really happy to see that we are now willing to take a first step toward multi-arch contributions / support. :) On 7/2/25 12:20 PM, Christian Hesse wrote:
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o
That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files.
Indeed, "any" doesn't mean "all" here. As said in the wiki [1], "any" is reserved for packages that can be built on any architecture, *and* once built, are *architecture-independent* in their compiled state (e.g. shell scripts, fonts, themes, etc...). [1] https://wiki.archlinux.org/title/PKGBUILD#arch -- Regards, Robin Candau / Antiz
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse <list@eworm.de> said:
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o
That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files.
yeah. i just found out - i never did that before. i was assuming it'd use $ARCH ... what's would be the way to go for "this will work on any arch - it's portable" without having to just list every arch i can think of?
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
-- Carsten Haitzler <raster@archlinux.org> Carsten Haitzler <raster@rasterman.com>
On 7/2/25 6:29 PM, Carsten Haitzler wrote:
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse <list@eworm.de> said:
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o
That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files.
yeah. i just found out - i never did that before. i was assuming it'd use $ARCH ... what's would be the way to go for "this will work on any arch - it's portable" without having to just list every arch i can think of?
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
makepkg/pacman does not support a meta architecture like `all`. Packages will need to explicitly opt for all supported architectures we expect to ship in Arch Linux. Please keep the arch=() array limited to architectures we actually do handle officially, which currently is only x86_64 :) Cheers, Levente
On Wed, 2 Jul 2025 21:25:22 +0200 Levente Polyak <anthraxx@archlinux.org> said:
On 7/2/25 6:29 PM, Carsten Haitzler wrote:
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse <list@eworm.de> said:
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o
That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files.
yeah. i just found out - i never did that before. i was assuming it'd use $ARCH ... what's would be the way to go for "this will work on any arch - it's portable" without having to just list every arch i can think of?
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
makepkg/pacman does not support a meta architecture like `all`. Packages will need to explicitly opt for all supported architectures we expect to ship in Arch Linux.
i had ignored this until now as arch was just x86-64... with the move to multi-arch support i had hoped i'd have a "ok - this packaged i know works on anything... so can i now just say that in the package" and know if there is a rebuild server for any given arch, it'll just work with my packages without further work. this would avoid pointless churn that every time someone wants to add more arch's ... you don't have to mobilize the entire packaging team for every package... you do it only for those packages that do have explicit arch deps.
Please keep the arch=() array limited to architectures we actually do handle officially, which currently is only x86_64 :)
well the point of this mail is to begin preparing the way for handling other arch's - as above. i'd have wanted to just drop specific arch's entirely as i know they are a non-issue. it'd be a one-off fix to then never have to care again and i'd be prepared for the addition of multi-arch support in arch ahead of time. :) -- Carsten Haitzler <raster@archlinux.org> Carsten Haitzler <raster@rasterman.com>
On July 2, 2025 3:25:22 PM EDT, Levente Polyak <anthraxx@archlinux.org> wrote:
On 7/2/25 6:29 PM, Carsten Haitzler wrote:
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse <list@eworm.de> said:
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o
That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files.
yeah. i just found out - i never did that before. i was assuming it'd use $ARCH ... what's would be the way to go for "this will work on any arch - it's portable" without having to just list every arch i can think of?
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a++];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
makepkg/pacman does not support a meta architecture like `all`. Packages will need to explicitly opt for all supported architectures we expect to ship in Arch Linux. Please keep the arch=() array limited to architectures we actually do handle officially, which currently is only x86_64 :)
Cheers, Levente
That may be something worth considering in the future. As much as I dislike Fedora's package format, their decision to make architectures opt-*out* instead of opt-in has apparently reduced the friction of adding new architectures quite a bit. We should consider adopting that approach. Best, Campbell
On Thu, 03 Jul 2025 06:09:16 -0400 Campbell Jones <serebit@archlinux.org> said:
On July 2, 2025 3:25:22 PM EDT, Levente Polyak <anthraxx@archlinux.org> wrote:
On 7/2/25 6:29 PM, Carsten Haitzler wrote:
On Wed, 2 Jul 2025 12:20:49 +0200 Christian Hesse <list@eworm.de> said:
Carsten Haitzler <raster@rasterman.com> on Wed, 2025/07/02 11:00:
Next releases of anything I maintain shall be going arch=(any) as everything I maintain is fully portable anyway and always has been. My AUR pkgs already have a host of arch's in them and i'll simplify to any. No other changes needed.
That's probable a bad idea. :-o
That would set the arch "any" in the package metadata, which is not true if it contains architecture dependent data, like elf files.
yeah. i just found out - i never did that before. i was assuming it'd use $ARCH ... what's would be the way to go for "this will work on any arch - it's portable" without having to just list every arch i can think of?
-- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Best regards my address: */=0;b=c[a+ +];) putchar(b-1/(/* Chris cc -ox -xc - && ./x */b/42*2-3)*42);}
makepkg/pacman does not support a meta architecture like `all`. Packages will need to explicitly opt for all supported architectures we expect to ship in Arch Linux. Please keep the arch=() array limited to architectures we actually do handle officially, which currently is only x86_64 :)
Cheers, Levente
That may be something worth considering in the future. As much as I dislike Fedora's package format, their decision to make architectures opt-*out* instead of opt-in has apparently reduced the friction of adding new architectures quite a bit. We should consider adopting that approach.
Indeed. +1. I'd be all for an arch=(all) or arch=() which means all arch's implicitly... it will make it drastically easier for many packagers to adapt to a new multi-arch world ahead of time with no impact and less noise/maintenance. -- Carsten Haitzler <raster@archlinux.org> Carsten Haitzler <raster@rasterman.com>
On 7/3/25 12:09 PM, Campbell Jones wrote:
That may be something worth considering in the future. As much as I dislike Fedora's package format, their decision to make architectures opt-*out* instead of opt-in has apparently reduced the friction of adding new architectures quite a bit. We should consider adopting that approach.
This is also how alpine does it, looks like this in the APKBUILD: https://gitlab.alpinelinux.org/alpine/aports/-/blob/8a6b5840955a28cc5c24f4c8...
On Thu, 3 Jul 2025 at 19:01, kpcyrd <kpcyrd@archlinux.org> wrote:
On 7/3/25 12:09 PM, Campbell Jones wrote:
That may be something worth considering in the future. As much as I dislike Fedora's package format, their decision to make architectures opt-*out* instead of opt-in has apparently reduced the friction of adding new architectures quite a bit. We should consider adopting that approach.
This is also how alpine does it, looks like this in the APKBUILD:
https://gitlab.alpinelinux.org/alpine/aports/-/blob/8a6b5840955a28cc5c24f4c8...
Maybe makepkg should warn instead of fail when attempting to build for an architecture that's not in $arch. This would be less complicated than implementing "all" with exclusions. It would also make it easier to consume the often poorly-maintained packages of the AUR. With this, $arch remains useful for test/build/release automation to decide which arches to build for, and to check whether the package is arch-independent. Maybe arch-independent packages should even be using "arch=any" instead of "arch=(any)" to emphasize that "arch" can't contain any other elements.
participants (9)
-
Campbell Jones
-
Carsten Haitzler
-
Carsten Haitzler
-
Christian Hesse
-
David Runge
-
Jan Alexander Steffens (heftig)
-
kpcyrd
-
Levente Polyak
-
Robin Candau