On Mon, 2022-07-18 at 16:52 +0100, Luca Boccassi wrote: > On Mon, 2022-07-18 at 14:32 +0200, Helmut Grohne wrote: > > > 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?
Summarizing what we talked about on IRC yesterday evening: - both apt and aptitude appear to do the expected thing when resolving, even when the extra dependencies are not already installed - apt with non-standard external resolver aspcud does the wrong thing, even when the extra dependencies are already installed - apt with other non-standard external resolvers can't seem to be tested as resolution does not work at all and it errors out earlier So there is a very small chance that the dependency 'usrmerge | usr-is- merged' will do the wrong thing for some users, if aspcud is in use. perl:any being uninstallable and thus making apt/aptitude fall back the other way does not seem like a realistic situation that can happen without anyone noticing much bigger issues. The failure mode in either case is that a clear error and instruction to install usrmerge will be printed. As agreed, if this turns out to be a problem once the upload is in unstable, we can switch the dependency in i-s-h to be strictly on 'usrmerge' and vendor the dozen of Perl modules that are required by it, like Ubuntu did, but for now we'll stay the course. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
