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? Thanks, -- Nicolas Dandrimont Date: Sat, 28 Oct 2023 17:10:24 +0200 Message-ID: <87v8aqzstb.fsf@dandrimont.eu>
Attachment:
signature.asc
Description: PGP signature