[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)

[Luca Boccassi]

On Sat, 28 Oct 2023 at 16:11, Nicolas Dandrimont <olasd at 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.