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
