Hello everybody, sorry for the late reply... I have been quite busy lately, and I guess this will not change until next year.
Lukas Fleischer <[email protected]> on Sat, 2025/11/08 13:10: > 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. No, I think this would not help here. > 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. Similar, but I think we need to branch at a different point, between testing and staging: [extra] <- [extra-testing] <- [extra-staging], ^ `--- [extra-unstable] So order in pacman.conf would be: * extra-unstable * extra-testing * extra > This second layout would most likely need a related branching concept in > Git and brings up some other questions; e.g., Exactly. I think that is our main issue at the moment. This has has to be solved before we can proceed. > * 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. As the layout should look different I will not answer each point above, but give my answer here: * Users can enable -testing just they do now - no change. * Enabling -unstable requires enable -testing as well. If a package is both repositories the one in -testing is covered by the one in -unstable. * The choice is up to the user: -testing for "fresh" stable releases that are supposed to move to stable, -unstable (and -testing) for possibly unstable pre-releases. * With an soname rebuild in -testing the package would have to be rebuilt for -testing and -unstable. That's why -testing is required: Without it could work, but may fail with breakage in dynamic linking. Did that cover all your questions? -- 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);}
pgpHh1vNGT3xJ.pgp
Description: OpenPGP digital signature
