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
