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