[Piuparts-devel] Bug#1054898: piuparts.d.o: overhaul merged-/usr configuration to match the majority of installed systems (was: piuparts: drop unmerged-usr sid configuration for debci)

[Nicolas Dandrimont]

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 at dandrimont.eu>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/piuparts-devel/attachments/20231028/8a2d0e1b/attachment.sig>