Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
Hi Luca,
Thank you for providing such a detailed and well-rationalized plan for
moving forward. It removes quite an amount of uncertainty about where
we're heading. I've missed this kind of clarity in previous
conversations.
On Sun, Jul 17, 2022 at 12:56:14AM +0100, Luca Boccassi wrote:
> A MR is pending for debootstrap [1] to make use of this new package and
> 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.
Can I ask you to also work with the mmdebstrap maintainer to make sure
that merged-/usr and opting out of it works well there? Specifically,
I'd like to have it work without pulling the usrmerge package (and perl
module dependencies) both in a merged and unmerged (buildd) layout.
mmdebstrap used to have switches, but now mostly ignores /usr-merge (and
thus doesn't merge). If we do nothing, it'll pull in usrmerge and its
perl module dependencies with no easy way to opt out. I'm not sure what
the solution is, but I'm positive that you'll find a reasonable
compromise once talking to one another. mmdebstrap has tried to stay
away from custom set-up code, which makes this slightly non-trivial.
> 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
I think this setup is prone to breakage. While apt prefers the first
alternative, it doesn't have to pick it and other resolvers are even
more prone to picking non-default alternatives. Imagine one of the perl
modules being uninstallable. Even apt will pick the usr-is-merged
package in that scenario. Are you ware of this potential problem? Do you
have any ideas on how to handle it? To be clear: I do not think this
aspect to be a show-stopper. Let's just talk about it on a technical
level.
Let me propose something strange without having thought through the
implications in depth (i.e. it may be a totally bad idea):
What would happen if we were to replace the usr-is-merged package with a
"trivial-usr-merge" package? This package would actually perform a
/usr-merge in simplified conditions. Like usr-is-merged, it would refuse
to perform a merge on actual systems. However in the case of
non-container chroots (those not running init), it would perform the
merge in a simpler way that doesn't require additional perl modules and
doesn't come with the same amount of safety-guarantees.
A benefit of this approach would be that I could say mmebstrap
--include=trivial-usr-merge. Possibly though, this is a bad idea for
reasons I am not presently understanding well. Thank you for
considering.
> 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).
> It will not be necessary to initiate or complete the migration to
> merged-usr, and we will not hold back waiting for a resolution on it,
> given the maintainer has made his intentions abundantly clear on the
> matter as recently as four months ago [3]. The patch is presented
> simply because it will likely be necessary, in that or any other form,
> to lift the moratorium on moving files between packages manually,
> whenever the CTTE decides that should happen. Whatever happens (or
> doesn't) to that patch/bug will not hold back the plan discussed here.
It seems as if the ball on this is being dropped on procedural grounds.
Yes, we need to figure that part out and it does take too long.
However, I think that the technical bits should be solved in parallel.
Solving the procedural issues is much easier if the technical work is
ready. I ask you to resume work there. This was effectively requested by
RT as well. I think that many recognize that unmerged will go away
before too long regardless of whether one likes it. But we also want a
dpkg that can handle the layout in a less fragile way even when our dpkg
maintainer disagrees with that vision.
> Do any of the Technical Committee members believe that this plan does
> not comply fully with their decision quoted above?
The remarks concerning mmdebstrap (including trivial-usr-merge) are to
be understood without a ctte-hat. The alternative picking and dpkg patch
concerns are mild concerns raised with my ctte-hat.
Helmut
Reply to: