On Wed, 2021-08-18 at 10:43 +0200, Simon Richter wrote:
> Hi,
> 
> On 8/18/21 12:21 AM, Luca Boccassi wrote:
> 
> > On Tue, 17 Aug 2021 at 20:17, Simon Richter <s...@debian.org> wrote:
> 
> > > I agree that it's likely the only thing we can do with the version of
> > > dpkg that we ship now, and that will have to handle the upgrade for any
> > > users that move from one stable release to the next provided there is no
> > > project consensus to deviate from "apt dist-upgrade" as the preferred
> > > method of upgrading to the next release.
> 
> > That is the case only if the plan is to deprecate support for
> > external/third-party repositories/packages, since there's no way to do
> > the required per-package work on those, and this strategy can only
> > work (and that's a non-trivial assumption already, given so far it has
> > a 100% failure rate) if every single package that will ever be
> > installed on every single system is updated individually.
> 
> My expectation would be that there are rather few third-party packages 
> installing files into the directories we want to clear out, and we have 
> two years in which we can tell people to get these packages updated.

Given we are talking about /bin /lib and so on, there are many, many
that actually do. Most don't even use dpkg-buildpackage to build, let
alone debhelper, but third party systems like cmake/gradle, most often
than not vendored and pinned at a specific version. Or even worse
custom makefiles/scripts, which might not even be developed publicly.
The usrmerge approach deals with this just fine. What is the concrete
plan of action for the symlink-farm approach to 1) find them all out,
and 2) to update them all? There has to be one: otherwise there will be
an unspecified and unknowable large number of machines that forever
will be unable to run the proposed algorithm to switch from symlink
farm to actual usr-merged, with no path to move out of it, so the two
states will always have to be supported: symlinks farm and real merged-
usr.

> > Also the "unsupportable" statement is kinda hard to reconcile with the
> > reality of this being default on Ubuntu for 2+ years, which uses the
> > very same dpkg. It would be very useful to have someone from Canonical
> > comment on what problems are there in reality? Launchpad shows only 2
> > bugs, which appears to be both corner cases:
> > https://bugs.launchpad.net/ubuntu/+source/usrmerge
> 
> That is why I wrote "provided there is no project consensus to deviate 
> from "apt dist-upgrade" as the preferred method of upgrading to the next 
> release." This is what Ubuntu did.
> 
> We can repeat that, which will anger a lot of users.

What specific features/workaround/fixes/etc were implemented in the
Ubuntu upgrader to deal with merged-usr?

-- 
Kind regards,
Luca Boccassi

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

Reply via email to