On Mon, 2022-07-18 at 14:32 +0200, Helmut Grohne wrote: > 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. Is mmdebstrap used on buildds/piuparts/autopkgtest or similar infrastructure that is to be held back? AFAIK they all use deboostrap, hence I only looked at it, but I might be wrong. I ask because the answer has implications on the urgency of any solution, not because it shouldn't be handled. We can certainly have a discussion in parallel to see what's the best solution there. > > 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. From what I understand there is really no difference between a full system and a chroot from the implementation point of view. The things it deals with are various situations the directories can be in, but whether the system was booted or not doesn't seem to be handled differently at all. In other words, if a 'simplified' version with fewer dependencies was possible, it could be just used everywhere, I think? Regarding the failure mode, I think it is theorethically possible, but very unlikely? The package has 3 individual perl modules dependencies (one direct, libfile-find-rule-perl, and two transitive, libfile-find- rule-perl and libnumber-compare-perl) and that's it, they don't depend nor conflict or break with anything else, just perl:any. So you'd need a headless system, that is dist-upgrading without using apt, and that has somehow made perl:any uninstallable. Do we know if other resolvers have coverage via autopkgtest/piuparts, that would pick on these issues? > > 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. I am very very strongly against making any dpkg change be a blocker for this effort, for reasons already explained, and my reading of the last decision didn't require it either, unless I missed something? _If_ there was a strong guarantee that a working patch would be forcefully applied (say after being reviewed and approved by a CTTE member), then motivation to work on this could possibly be found, in parallel or after the rest of the workstream is completed. Right now I'm afraid motivation to do so is simply non-existing, because rightly or wrongly any work on this is perceived as being piped straight to /dev/null, and we are all on volunteer time here. > > 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. Thanks for chiming in! -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part