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

Re: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

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

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

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: