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

Re: merged-/usr vs. partially-symlink-farmed-root



Hi Guillem,

On Sun, 2021-08-22 at 00:11 +0200, Guillem Jover wrote:
> There was talk about the huge amount of symlinks required in a
> symlink
> farm setting, but that might have been true for a scenario where
> those
> symlinks would have been handled automatically and transparently.

To get a filesystem layout equivalent to merged-/usr via symlinks
farming *every* package shipping files in at least /usr/bin, /usr/sbin
and possibly some of /usr/lib would need to include symlinks in /bin,
/sbin, /lib.  This would affect far more packages than updating the
packages currently shipping files in /bin, /sbin and /lib* to ship
these under /usr instead.

Note that on a merged-/usr system it is fine, and will be fine forever,
to use /bin/python3 instead of /usr/bin/python3.

If this is not done, the layouts are even more different. So they
should be named differently to avoid people confusing them as minor
variants of the same: maybe merged-/usr and partially-symlink-farmed-
root (as not all compatibility symlinks exist).

> The huge majority of files under /lib* (which is the actual bulk of
> them)
> should require no symlink farms. Many of the ones under /bin and
> /sbin
> (we are talking about around 240 packages here) might be switchable
> w/o
> compat symlinks after careful consideration (or not…), many of the
> ones
> that require symlinks would need these just for a period of time,

Removing any symlink will cause software to break.

There was recently one such instance with `run-parts` getting moved to
/usr/bin. Is your proposal to repeat this for every binary in /bin and
/sbin (except possibly some selected ones) at one point in time?
There seems no realistic way to find/fix all software affected by this
beforehand, especially software outside of Debian. What is your
proposal to handle this?

Note that this breakage only happens with your newly proposed
partially-symlink-farmed-root filesystem layout that you propose
instead of merged-/usr.

>  and
> only a handful would remain (the ones that are part of standard
> interfaces, which I'd expect would be mostly shells?). I think the
> amount
> of symlinks currently provided by f.ex. lvm2 and e2fsprogs combined
> would
> amount to more symlinks than what we would eventually end up with
> TBH.

So your proposal is to adopt a partially-symlink-farmed-root layout and
never switch to merged-/usr? Sure, in that case SuSE failing to move
from partially-symlink-farmed-root to merged-/usr is not an argument
against that. But it still is a good argument against adopting
partially-symlink-farmed-root as a way to get to merged-/usr.

What are the advantages to moving to a new filesystem layout used only
by Debian which introduces incompatibilities with other distributions?

Are there further disadvantages we have not yet found?

> Luca posted a mess of disinformation.
[...]
> Or there's the following for example:
> 
> > IN particular, most systems are usrmerged today, and while these
> > bugs
> > are annoying, many people get along just fine.
> 
> That would imply that most people have either gone out of their way
> to
> explicitly install and run usrmerge or they have reinstalled from
> scratch. I cannot believe the first to be of any significance, the
> second would put into question why we bother supporting release
> upgrades
> (after all many other distros do not support that, we perhaps should
> catch up with what the rest of the world is doing!).

Various distributions outside of Debian seem to recommend installing
usrmerge on upgrade, for example Ubuntu or Linux Mint, with Ubuntu also
pulling in the usrmerge package on upgrades by default. So by now there
likely is a significant population of such users.

I also don't see people doing new installations as a problem: people
not only using Debian on existing installations that might be a decade
old, but also deploying it on new systems is a good thing.  I don't
think people doing so has any implications to question supporting
upgrades or not.  (Besides totally new systems there are of course
other valid reasons to start from a clean slate instead of upgrading an
existing system such as having a documented state or just automated
deployment.)

To be honest the conjecture that the number of people having installed
Debian or Ubuntu or other Debian-based distributions in the last few
years is insignificant and can be totally ignored feels rather far
fetched just to support an outcome you want to see true.  We would have
much, much larger problems for the future of Debian and Debian-based
distributions than merged-/usr if this was true.  So if you have any
support for this claim, I'm interested in seeing it.

Ansgar


Reply to: