Hello everybody, for some time I used to push rc release for some packages (namely systemd & util-linux) to core-testing. This broke once, when a package was built against that rc release and thus did depend on new symbols, then finally was moved before the package it was built against. After that I pushed all the rc releases to a public personal repository, anybody interested could test from there. But I think the audience was a lot smaller, and last systemd release revealed some unexpected regressions *after* final release. That situation is not any better, especially when rc releases in Arch were a major factor in finding regressions early. At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository. I guess we have three places that need to be touched: * create repositories on servers (-> DevOps) * dbscripts * devtools Anything more? Feedback is welcome, same for other ideas - this is not set in stone and I am open for anything that works for me/us. Thanks! -- 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 07/11/2025 14:48, Christian Hesse wrote:
Hello everybody,
for some time I used to push rc release for some packages (namely systemd & util-linux) to core-testing. This broke once, when a package was built against that rc release and thus did depend on new symbols, then finally was moved before the package it was built against.
After that I pushed all the rc releases to a public personal repository, anybody interested could test from there. But I think the audience was a lot smaller, and last systemd release revealed some unexpected regressions *after* final release. That situation is not any better, especially when rc releases in Arch were a major factor in finding regressions early.
At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository.
Short feedback from my side, how does this work in terms of hierarchy? I assume [extra-unstable] would be above [extra-testing] and not [extra-staging]?
Jelle van der Waa <jelle@vdwaa.nl> on Fri, 2025/11/07 14:59:
Short feedback from my side, how does this work in terms of hierarchy? I assume [extra-unstable] would be above [extra-testing]
Yes.
and not [extra-staging]?
Hmm, would these ever be used in one configuration? I think end users (even testers) should not have [extra-staging] in their configuration as it is used for rebuilds and thus breaks by design. On the other hand [extra-unstable] should never be used for building, at least not any packages that are supposed to go to a different repository than [extra-unstable]. So any situation we have to define a correct order? -- 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 November 7, 2025 8:48:07 AM EST, Christian Hesse <list@eworm.de> wrote:
Hello everybody,
for some time I used to push rc release for some packages (namely systemd & util-linux) to core-testing. This broke once, when a package was built against that rc release and thus did depend on new symbols, then finally was moved before the package it was built against.
After that I pushed all the rc releases to a public personal repository, anybody interested could test from there. But I think the audience was a lot smaller, and last systemd release revealed some unexpected regressions *after* final release. That situation is not any better, especially when rc releases in Arch were a major factor in finding regressions early.
At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository.
I guess we have three places that need to be touched:
* create repositories on servers (-> DevOps) * dbscripts * devtools
Anything more?
Would -unstable also go through the sign off process? If so: - arch-signoff - archweb
Feedback is welcome, same for other ideas - this is not set in stone and I am open for anything that works for me/us. Thanks!
-- Best, Daniel <https://danielcapella.com>
"Daniel M. Capella" <polyzen@archlinux.org> on Fri, 2025/11/07 09:20:
I guess we have three places that need to be touched:
* create repositories on servers (-> DevOps) * dbscripts * devtools
Anything more?
Would -unstable also go through the sign off process? If so:
- arch-signoff - archweb
As these packages are not intended to be moved to [core] or [extra]... No. Once the rc phase is done the rc packages would be dropped from [core-unstable] and [extra-unstable], and the final packages would go their way through [core-testing] and [extra-testing] to finally land in [core] and [extra]. -- 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);}
Am Freitag, dem 07.11.2025 um 14:48 +0100 schrieb Christian Hesse:
Hello everybody,
Hey 👋️
At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra- unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository.
Is this also supposed to replace {gnome,kde}-unstable? I have a hard time imagine how testing this should be done if multiple packages are in alpha/beta that might even depend on each other in some way. To be clear - Most of the time I consider gnome-unstable completely broken. Just a dumping ground for new pre-releases and for users who deal themself with this mess until it becomes more reliable. 😂️ I'd like to keep it this way. Would -unstable depend on core- and extra-testing or on the "stable" repos?
Fabian Bornschein <fabiscafe@mailbox.org> on Fri, 2025/11/07 16:04:
Is this also supposed to replace {gnome,kde}-unstable? I have a hard time imagine how testing this should be done if multiple packages are in alpha/beta that might even depend on each other in some way.
This is to be discussed, but I think I would tend to keep it separated. Someone who wants to test rc releases of systemd or util-linux is not necessarily in search for trouble with unstable gnome. :-p Though someone could enable [core-unstable], but skip [extra-unstable]...
To be clear - Most of the time I consider gnome-unstable completely broken. Just a dumping ground for new pre-releases and for users who deal themself with this mess until it becomes more reliable. 😂️ I'd like to keep it this way.
I have not tested anything from these repositories... Can't tell.
Would -unstable depend on core- and extra-testing or on the "stable" repos?
At least my packages would be in a state the having stable und unstable, but skipping testing, would be just fine. -- 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);}
Christian Hesse <list@eworm.de> on Fri, 2025/11/07 20:40:
Would -unstable depend on core- and extra-testing or on the "stable" repos?
At least my packages would be in a state the having stable und unstable, but skipping testing, would be just fine.
Looks like this is a bad idea. Let's assume we have something in testing with an soname bump - for example openssl, and systemd is rebuilt as well. With systemd in [core-unstable] we want it to work in any case, so yes - depending on [core-testing] and [extra-testing]. (Though it may work without most of the time.) Thanks to Mike Yuan for giving the hint! -- 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);}
El viernes, 7 de noviembre de 2025 a las 14:48 Christian Hesse escribió:
At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository.
I guess we have three places that need to be touched:
* create repositories on servers (-> DevOps) * dbscripts * devtools
Anything more?
How would that work on the git repo level? Do you update to the unstable version in main? In that case, what happens if the package needs a rebuild in the stable repos?
Antonio Rojas <arojas@archlinux.org> on Fri, 2025/11/07 16:11:
How would that work on the git repo level? Do you update to the unstable version in main? In that case, what happens if the package needs a rebuild in the stable repos?
Ah, really good question... Have not thought about that. How is this done for Gnome and KDE at the moment? Anybody involved there can elaborate? For the packages in my personal repository I use a separate branch and the changes are just dropped once the final packages go to official repositories. For sure we do not want that when packages go to official unstable repositories. -- 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);}
El viernes, 7 de noviembre de 2025 a las 20:44 Christian Hesse escribió:
Antonio Rojas <arojas@archlinux.org> on Fri, 2025/11/07 16:11:
How would that work on the git repo level? Do you update to the unstable version in main? In that case, what happens if the package needs a rebuild in the stable repos?
Ah, really good question... Have not thought about that.
How is this done for Gnome and KDE at the moment? Anybody involved there can elaborate?
We use separate branches. This workflow was broken by the move to git though, and hasn't been fixed yet, so the procedure is quite hackish now as we need to bypass the limitations of the official tools. I'm hoping this proposal will make this finally be sorted out on the devtools side.
Quoting Christian Hesse (2025-11-07 08:48:07)
At Arch Summit 2025 we had a chat about that situation and discussed several ideas. In the end we came up with one reasonable solution: We should introduce new repositories [core-unstable] and [extra-unstable] for this kind of testing. People would still have to enable these repositories, but I guess chances are higher than for my personal repository. [...] Feedback is welcome, same for other ideas - this is not set in stone and I am open for anything that works for me/us. Thanks!
Thanks for the idea! Even though I don't think this isn't the "right" "full" solution to a broader underlying challenge (e.g., it doesn't really address closely related issue of overlapping rebuilds), I love taking a simple and pragmatic approach here. Having read through the thread, I am still slightly unsure I understand the proposed layout. Is it (i) a linear chain [extra] <- [extra-unstable] <- [extra-testing] <- [extra-staging], where the core principle that packages earlier in the chain (i.e., further right in the illustration above) are "newer" packages and correspond to "more recent" Git commits? This is a layout that'd work well with the current Git structure but has other implications, such as unstable releases always "blocking" overlapping rebuilds; i.e., the rebuild adopts the unstable release and can only move once the unstable release is ready to move too. I believe it also wouldn't address the example you brought up in the initial email. Or is a better way to think of it as (ii) a branched repo [extra] <- [extra-testing] <- [extra-staging], ^ `--- [extra-unstable] where the order in the pacman configuration would probably still be the same as above but there's now branched package history/evolution. This second layout would most likely need a related branching concept in Git and brings up some other questions; e.g., * Can I enable -testing and -unstable repos at the same time or are they mutually exclusive? * How should I, as a user, choose between -unstable and -testing repos? * If -testing and -unstable can be enabled at the same time, what happens if there's an -unstable version of the package while the package is part of some ongoing rebuild at the same time? Does the rebuild or the -unstable version "win"? Or do we need to rebuild the -unstable version as well when it moves to -testing (which seems to imply that -testing and -unstable now *must* be enabled together to avoid breakage)? * In either case, what happens when a rebuild enters the stable repos; are we expected to rebuild all potentially affected -unstable packages as well? It'd be good to have provisional answers here and flesh them out in an RFC if we'd like to move forward. Thanks again! Lukas
participants (6)
-
Antonio Rojas
-
Christian Hesse
-
Daniel M. Capella
-
Fabian Bornschein
-
Jelle van der Waa
-
Lukas Fleischer