On Sat, 28 Oct 2023 at 16:11, Nicolas Dandrimont <ol...@debian.org> wrote: > > Bcc: > Reply-To: > Control: retitle -1 piuparts.d.o: overhaul merged-/usr configuration to match > the majority of installed systems > Control: tags -1 - patch > > Cc'ing Helmut & the release team as a heads-up. > > Hi Luca, > > Thanks for submitting this bug and proposing a patch. To recap, piuparts tests > in sid are currently broken because the usr-is-merged package fails to upgrade > since it's removed support for the exemption flag (as piuparts uses > unmerged-/usr chroots with the flag file, which is not supported anymore). > > Before rushing to fix this with one more hack, I'd like to have a look at what > we want piuparts to be testing from first principles again. > > In short, I think we've made a mistake by having piuparts use unmerged-/usr > chroots during the bookworm development cycle, and I'd like to fix that now. > > As far as I understand, this is our "support matrix" > > | distro | build chroots | installed system support | layout for > new installs | > | ---------- | ------------- | --------------------------------- | > ----------------------- | > | sid (&exp) | merged-/usr | merged-/usr only | merged > | > | trixie | merged-/usr | merged-/usr only | merged > | > | bookworm | unmerged-/usr | merged-/usr only | merged > | > | bullseye | unmerged-/usr | merged or unmerged | merged > | > | buster | unmerged-/usr | merged or unmerged | merged > | > | stretch | unmerged-/usr | unmerged or merged (experimental) | unmerged > | > | jessie | unmerged-/usr | unmerged-/usr only | unmerged > | > > In practice, as piuparts has been running almost exclusively on unmerged-/usr > chroots, and only running a narrow set of sid tests on merged-/usr chroots, it > has been running its (package install and upgrade) tests mostly against a > non-default setup, catching issues that would have been most relevant for > build > chroots. > > I believe that we should be doing the following now: > > - Update the piuparts config to default to generating and using merged-/usr > chroots for all suites. Upload piuparts to sid. > - Replace all base chroots from buster and up on piuparts.debian.org with > merged-/usr chroots > - (maybe) add unmerged variants of the bullseye-pu and bookworm-pu tests to > make > sure we can still use these packages in buildd chroots > > There is the question of what to do for piuparts.d.o tests that involve > upgrading the base chroot across the unmerged-/usr support boundary, but > switching over to only using merged-/usr base chroots for buster and up will > alleviate that (I don't think we have any archaeological tests starting from > stretch running anymore). > > Alternatively, I've poked a little bit at running the usrmerge script in a > pre_distupgrade piuparts hook, which is a bit awkward as these hooks are run > after the sources.list is updated for the target suite. It's just a matter of > adding a new class of hooks (pre_sourceslistupdate or something) and > implementing usrmerge in that. I'm not sure it's worth the hassle compared to > the efforts already put into dumat. > > As far as I can tell, to guard testing migration, the release team is > comparing the results of piuparts running on the package in trixie, with > the results of piuparts running on the package in sid. I'm not sure that > upgrades (that is, testing2sid) are involved, so, as long as the chroots > are consistent between the trixie tests and the sid tests, these exports > should keep making sense for the release team. > > Does my reasoning make sense?
Your reasoning makes sense to me, thanks. At this point we are already past the upgrade-across-boundary phase, so I wouldn't spend extra time on that.