[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tech-ctte: more on merged-/usr



On Sun, 17 Jul 2022 at 00:56:14 +0100, Luca Boccassi wrote:
> Piuparts has been enhanced with a new test case that covers the
> moratorium on moving files manually between their location in the root
> directories and /usr.

Thanks for doing this, it will help a lot.

> A MR is pending for debootstrap [1] to make use of this new [...]
> file flag when --variant=buildd is passed, so that buildds can continue
> to be unmerged-usr until the CTTE says otherwise, as per decision
> above.

I don't think we actually ever said that buildds must continue to be
unmerged-/usr. In #914897 we resolved that for Debian 11, build systems
can validly be either merged-/usr or unmerged-/usr, implicitly meaning
that packages that are mis-built on either merged-/usr or unmerged-/usr
buildds have a bug (#994388 recommended that this bug is treated as RC).
In #994388 we confirmed that this continues to apply during the
bookworm-is-testing cycle.

In #914897 this narrowly defeated the alternative of mandating that build
systems must be merged-/usr for Debian 11 (which, with hindsight, would
have been too disruptive at that time, and I'm glad we didn't choose it).

I personally agree that buildds should stay unmerged-/usr until the known
bugs that would be triggered by merged-/usr buildds have been raised to
RC severity, though. #992645 is a typical example. I'll try to have a look
at those bugs today.

The QA systems that I had in mind when I suggested that we need an
opt-out were things like autopkgtest and piuparts, rather than buildds,
to ensure that we can detect this scenario:

* a package (let's say ncftp, #992645) is built on a merged-/usr buildd
* it builds successfully, but the contents are incompatible with
  unmerged-/usr systems
  - for example in #992645 the binary gets /usr/bin/tar hard-coded into it,
    but that path only exists on merged-/usr
* a QA test (autopkgtest, piuparts or similar) installs the package into
  an unmerged-/usr environment
* the package fails to install, or installs but fails to work
  - I don't think ncftp has a test that exercises its tar integration,
    but please imagine it did...
* as per #994388, the TC think this should be treated as a RC bug

The opt-out is needed in order to allow autopkgtest and piuparts to create
the necessary unmerged-/usr environment to be able to run that test. If
they can only create merged-/usr bookworm environments, then that test
would not be implementable.

> Once deboostrap is updated and deployed on the buildds, a "usrmerge |
> usr-is-merged" dependency will be added to the Priority: essential
> init-system-helpers package, and uploaded to unstable to complete the
> transitions for all installations that are older than buster or that
> have been manually installed as unmerged-usr. Any system not upgraded
> will be considered unsupported, and any package that doesn't work on
> the only supported layout will be considered RC-buggy, as per decision
> above. No special installation or upgrade path will be necessary, the
> normal apt upgrade/install process works as expected, and the
> transition happens from a maintainer script and it does not require to
> be ordered before or after any other package installation or upgrade.

This all seems like a reasonable course of action to me. The usr-is-merged
package avoids the dependency impact of the Perl modules that usrmerge
needs when it does the actual transition.

After usrmerge has been installed successfully, is it straightforward to
replace it with usr-is-merged so that usrmerge's Perl dependencies can be
autoremoved?

> The patch from user uau that the dpkg maintainer rejected in the past
> has been submitted to the existing bug [2] for completeness (with
> permission from the author).

If I remember correctly, Julian Andres Klode was developing a version
of this patch that replaced the hard-coding of the /usr merge with a
more general way to declare "directory A is an alias for directory B"
and have it stored in the dpkg database, so that dpkg has the mechanism
and some Essential package like init-system-helpers or base-files could
have the policy, in the hope that this would be more acceptable to the
dpkg maintainer. Is that code available?

    smcv


Reply to: