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
