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

Bug#1050001: Unwinding directory aliasing



On Fri, 18 Aug 2023 at 07:57:14 +0100, Ian Jackson wrote:
> I think we can probably fix it by backing out this change, and then
> doing usrmerge the traditional Debian way by making changes to
> debhelper, so that we move the files package by package, in the .debs.

What do you consider to be the end goal of this proposal?

If I understand your proposal correctly, it is to return all Debian
systems to their traditional (let's say circa 2010) layout, and then
restart the transition differently. Imagine for a moment that the
usrmerge package, debootstrap --merged-usr, etc. had never existed,
and all Debian systems were in their 2010 state (or equivalently, that
your proposed revert has happened and we are now ready for the second
stage of your plan).

If we carry out this transition package-by-package without central
coordination ("the traditional Debian way"), it seems to me that the
best we can achieve is for /bin, /sbin, /lib* to be symlink farms,
consisting of symlinks that are either owned by the same package that
owns the symlink target, or are unowned from dpkg's perspective and are
created by maintainer scripts.

Here's a simplified view of the resulting system:

/bin/sh -> /usr/bin/sh
/bin/rm -> /usr/bin/rm
/usr/bin/env (regular file)
/usr/bin/sh (regular file)
/usr/bin/perl (regular file)
/usr/bin/rm (regular file)

(Obviously in real life, /bin and /usr/bin are a lot larger than that,
and /sbin and /lib* are also necessary for a bootable system, but
considering a small number of /{usr/,}bin files is enough to illustrate
my point.)

This does some but not all of what merged-/usr does: calling /usr/bin/sh
would become a non-bug, but calling /bin/env would still be an error,
/bin would still represent non-trivial on-disk and/or in-dpkg-database
state, and we would still potentially have other issues triggered by
the directories being distinct from one another (like the one discussed
by the tech committee in #911225, which was exactly a regression caused
by having moved a library in the traditional Debian way).

The merged-/usr version of that same simplified system is this:

/bin -> usr/bin
/usr/bin/env (regular file)
/usr/bin/sh (regular file)
/usr/bin/perl (regular file)
/usr/bin/rm (regular file)

(Again, in real life we also have to consider /sbin and /lib*, but
showing /bin is enough to illustrate the difference.)

As was discussed in 2019 and repeatedly since then, some of the reasons
to want merged-/usr are only available with that layout, and are not
provided by the symlink farm.

If I remember correctly, openSUSE tried to get from unmerged /usr to
merged /usr by essentially the route you propose, successfully reached
the symlink-farm state, but then got stuck without a way to get from the
symlink farm to the single symbolic link. Do you have a plan for how that
would be achieved without breaking upgrades or going behind dpkg's back?

If your plan was a longer, slower, arguably more robust way to achieve
the same end goal, that would be more appealing than a longer, slower,
arguably more robust way to get halfway to the same end goal and then
become unable to go further.

    smcv


Reply to: