[gentoo-dev] /usr merge Was: [PATCH 00/21] gen_usr_ldscript: migrate away from a sep-/usr by default

[Duncan]

Alexis Ballier posted on Mon, 04 Apr 2016 09:12:16 +0200 as excerpted:

>> The /usr merge is a separate issue, which I agree with as well, but
>> that was never brought to council, and it is controversial in the
>> Gentoo camp because some folks claim fhs doesn't allow it.
>
> Getting a bit OT, but can you explain in what ways it violates fhs ?
> What worries me more about /usr merge is that I've never seen a plan for
> it. I think it'd be necessary to have portage gain some intra-package
> collision check (e.g. a package installing /bin/foo and /usr/bin/foo
> should be reported), which would then allow building /usr-merged stages,
> but the main issue for me is how to migrate installed systems properly.

FWIW, I actually run a (reverse) merged /usr here, along with the bin/sbin 
merge.

Obviously it's symlinks as the packages still install where they will 
install, but:

/usr -> .
/sbin -> bin

As a result I have the following "semi-flattened" directory structure 
directly on /, including everything that would normally be under /usr:

/bin
/boot
/dev
/etc
/games -> .
/home
/include
/lib -> /lib64
/lib64
/libexec
/local
/media
/proc
/root
/run
/sbin -> bin
/share
/src
/srv
/sys
/tmp
/usr -> .
/var
/x86_64-pc-linux-gnu

(That excludes some unrelated additional changes of my own, again mostly 
to shorten paths, such as /home actually being /home -> /h (/h being the 
actual mountpoint for what would normally be /home in fstab), /local, 
what would be /usr/local, actually being /local -> /l, and /var/log -> /
lg (with /lg being a mountpoint as well, isolating logs and keeping 
runaway logging from creating havoc on anything but /lg itself).)


You will be glad to note that portage has in fact been smart enough to 
avoid symlinks overwriting the files they would normally point at for 
quite some time -- in fact, I specifically asked about this on the 
portage list before I tried it myself.  So that's not a problem at all.

There are, however, occasional bugs when specific packages try to clean 
up old versions and end up deleting the new version instead, because they 
don't dereference symlinks to a canonical path before they do the rm.  
One current example of that is gcc-config:

[Bug 554334] sys-devel/gcc-config pkg-postinst rm -f /usr/sbin/gcc-config 
breaks when using /usr/sbin->bin symlinks

https://bugs.gentoo.org/show_bug.cgi?id=554334

The result of that bug is that gcc-config deletes its own executable.  
However, it's worth repeating that the bug is because the ebuild itself 
executes rm -f on an arbitrary path without resolving both it and the 
canonical path of its executable and comparing them -- it's not a bug in 
portage itself, portage itself behaves correctly in terms of resolving to 
canonical paths.

Fortunately for me, while that bug has been open for 8 months+, my sync 
script can automatically patch ebuilds using patches in /etc/portage/
patches.ebuild, much like the portage implementation of eapply_user 
patches sources with patches found in /etc/portage/patches.  So now I've 
worked around that bug by patching out the offending rm line in the 
ebuild.  Hey, when eight months and counting later a critical bug in a 
toolchain package remains open, a good gentooer tends to find 
workarounds.  What can I say?


Packages that use cmake can sometimes have issues too, depending on the 
version of cmake, as it apparently doesn't always properly resolve to 
canonical paths.  As I'm a kde5/plasma user and one such affected package 
has been baloo, a plasma dependency, that has been a headache for me.  
But being a USE=-semantic-desktop user in the kde4 era, I didn't really 
want baloo on my system anyway, so rather than spend the time researching 
how to fix the bad cmake/symlinks interaction, I was motivated to 
research killing the baloo deps instead, and ultimately source-patched 
(as opposed to ebuild-patched, as I did gcc-config) the two plasma 
packages requiring it to kill the baloo-based modules.  With the sources 
patched to no longer require baloo, I simply placed a baloo null-package 
in my overlay (the other alternatives would be package.provided, but 
that's deprecated, or to use the ebuild patching sync-script mentioned 
above to delete the baloo-deps in the ebuild) to fill the ebuild 
dependency, and that's what I'm running with today.

The merged /usr and bin/sbin cmake related bugs I've filed are:

cmake/baloo: https://bugs.gentoo.org/show_bug.cgi?id=561956

(Unrelated to /usr or bin/sbin merge but mentioned above as my resolution 
for the cmake/baloo bug, the no-baloo patches bug:
https://bugs.gentoo.org/show_bug.cgi?id=578664 )

Older cmake/libraw bug, resolved with newer versions of one or the other: 
https://bugs.gentoo.org/show_bug.cgi?id=532426

Older plasma5 plasma-desktop bug that kept the plasma5 desktop from 
coming up properly, as I was switching to it from kde/plasma4, so I'm not 
sure if it was a regression from earlier plasma5 or not.  Fixed in 
current plasma: https://bugs.gentoo.org/show_bug.cgi?id=570210

IIRC I had one other /usr or bin/sbin related bug a couple years ago 
shortly after I first did the merge, but IDR what it was well enough to 
search my bugmail archive for it and get a link.

With nearly 1000 packages installed and 316 listed in various sets found 
in my world_sets file, that's all the /usr and bin/sbin merge bugs I've 
seen in what I'd guess to be two years plus of running merged, so it's 
obviously not a common problem at all.

And of course if gentoo more officially supported the /usr and bin/sbin 
merges, I'd have probably never seen half those bugs, as they'd have been 
caught before I ever saw them, even on ~arch.  Tho of course there'd be 
other bugs filed by others, for packages I don't have installed here.

But a merge-related bug is still relatively rare.  It's gotta be less 
than half the bugs I file and I'd guess 20% or less, and my setup is rare 
enough that were it mainstream, most users, certainly by stable, would be 
unlikely to ever see a /usr or bin/sbin merge related bug at all.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman