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 <sjr@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