On Tue, Feb 19, 2019 at 05:49:24AM +0100, Guillem Jover wrote:
> Hi!
>
> On Tue, 2018-11-20 at 22:16:17 +0100, Adam Borowski wrote:
> > Thus, it seems to me that the plan A for usrmerge has serious downsides for
> > dubious benefits. What about the plan B I described above?
>
> So, people still seem to be conflating merged-/usr (the filesystem
> layout) with the different ways to deploy it. Personally I do agree
> that merged-/usr has benefits, and that's why I've f.ex. been switching
> the shared library packages I maintain to do a proper and correct switch
> by installing their files in /usr/lib instead of /lib.
>
> The underlaying problem with the merged-/usr-via-symlinks is not
> really that it has generated bugs, many transitions we perform incur
> those, for the better. The problem is that it has generated those when
> it was really not necessary in the first place, has made things
> unnecessarily more complicated for everyone, and it's a terrible hack
> trying to reap "quick" benefits at the cost of everyhing else, with
> long lasting consequences even after a full migration to /usr would
> have been finished. And here's why:
>
> 1) The merged-/usr-via-symlinks deployment method used by both
> debootstrap and usrmerge, means that those systems will get
> permanent filesystem aliasing problems, forever. Even when all
> files might have been moved to their /usr counterparts in the
> packages! This is due to the fact that different pathnames can
> end up pointing (before any canonicalization!) to the same dentry.
This is IMO the most important feature of usrmerge: It does not matter
whether you use /usr/$bar or /$bar, you'll get the same result. Hence
/bin is a symlink to /usr/bin and so on, so you get the same binaries
and libraries in both places.
Having symlinks in /bin and so on would be unclean: We'd have to maintain
one symlink per binary in /usr. This is a lot of symlinks. We also cannot
ever get rid of them - it would break the property.
It also fails to handle subdirectories in lib{exec}. We do want
/usr/lib/systemd and /lib/systemd to be the same.
I don't think there is any other way that sensible handles merging
subdirectories, and therefore, the only reasonable way is to continue
with the current way, and patch up software to normalize /{bin,sbin,lib}
to /usr/bin when they see it on an usrmerged system.
I admit that this is painful, but I think it is worth it.
> 2) It bypasses the packaging system understanding of what is on the
> filesystem and creates mismatches between what's on binary packages
> and what's on disk.
I agree that this is a problem. But it seems to me it is a solvable
one.
> 4) Due to having to support the broken merged-/usr-via-symlinks
> deployment, when we want to move the contents of the binary
> packages to the merged-/usr layout, we require now to include tons
> of logic in (probably new) maintainer scripts, when we have been
> trying to remove them altogether. :( With even more files untracked
> by dpkg itself, bypassing the packaging system even more, when the
> compat symlinks could have been shipped in the binary packages.
The solution here seems simple: If you do not want a usrmerged
system, but do want to move binaries to /usr, build a symlink farm
manager into dpkg that automatically creates symlinks in /$foo for
files in /usr/$foo (for some values of $foo), rather than having
packages ship compat themselves.
That would get you support for merged binaries and libraries, but
not for merged lib directories. It's unclear to me how you'd handle
those, hence I mentioned that /lib -> /usr/lib is the only sensible
answer.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
