Jonathan Callen posted on Wed, 02 Jul 2014 19:06:59 -0400 as excerpted: > On 07/02/2014 02:14 PM, Duncan wrote: >> Rich Freeman posted on Wed, 02 Jul 2014 09:30:50 -0400 as excerpted: >> >>> Some things to think about include multilib (just another arch?), >>> systemd, and usr-merge. >> >> FWIW, systemd with merge to / (/usr being a symlink to . and sbin to >> bin) here. In particular, the merge "just works" with current portage. >> I'm no-multilib. >> > That merge only works because you happened to get lucky, and have > portage merge coreutils in a particular manner (/usr/bin/uname installed > before /bin/uname). If portage had installed /bin/uname first, you > would have ended up with a /bin/uname symlink pointing to /bin/uname. > The same is also true of basename, chroot, cut, dir, dirname, du, env, > expr, head, mkfifo, mktemp, readlink, seq, sleep, sort, tail, touch, tr, > tty, vdir, wc, and yes.
No, it works because, as I specifically asked the portage folks about before I tried it, portage has had symlink merge intelligence for some time now. Apparently well before I asked (in May, 2013, according to my portage-devel list archives), some portage dev considered the possibility of directory symlinks triggering overwrites of targets with the symlinks pointing to them, and ensured that portage's qmerge code "just did the right thing." I did nothing with the answer for some time, but eventually decided to try it. As I was a bit skeptical/careful at first, after doing the initial manual moves and thus finding which files existed in both target dirs, then deleting the individual file symlinks, moving the remaining files to the new location and making the old directory a symlink, I equery-belonged the symlinks and manually remerged (from binpkg, which still stores the symlinks in their usual location in the binpkg tarball) several of the packages one at a time, first a non-critical one, then I think coreutils itself, just to be sure, then 2-3 others together, and sure enough, it "just worked" the way it was supposed to work. =:^) > I myself am currently running a system with the opposite merge (/bin, > /lib, /lib64, and /sbin are symlinks to /usr/bin, /usr/lib, /usr/lib64, > and /usr/sbin) although I do not yet have the sbin -> bin merge yet. FWIW I decided the single /usr -> . symlink was simpler, and besides, I liked the shorter direct paths. =:^) And I did the /usr merge first, thinking I wanted to keep the bin/sbin distinction at first, until sometime later I decided to simplify my PATH var to remove /usr, and realized I had sbin in my normal user's PATH too. Completing the merge would/did allow me to simplify PATH even further, and since I has sbin in my normal user's PATH, there really wasn't a reason to keep them separate at that point, and I was already comfortable with merged bins by then anyway, so it wasn't much of a stretch at all. > I > added a post_src_install and post_pkg_preinst hook in my > /etc/portage/bashrc to ensure that there are no conflicts before the > package is merged and a pre_pkg_setup hook to disarm gen_usr_ldscript > (so as not to create a conflict). That's all unnecessary, because as I said, in general portage "just works" with the merge now, since it's designed to work with pretty much /any/ strange site-specific symlinking local gentoo admins might throw at it, altho I expect the ldcache stuff is still doing a bunch of extra work by going over all the dirs that are actually the same thing, and I suspect revdep-rebuild (which I still run religiously after every @world update) is doing a bunch of extra scanning too. But as I'm on SSD the extra filesystem IO isn't a big issue, meaning it's simply the CPU cycle cost, and so far simply spending the extra CPU cycles has been cheaper for me than actually researching what I might do about it, so... > The only two packages I have installed that I had to modify to make this > work were coreutils (as noted above) and plymouth. I did find one package with a specific post-install quirk, that was there to work around a binary move from many years ago, that ended up specifically removing the binary after portage had done its thing and actually put the binary in place instead of the symlink, but that binary wasn't a system-critical binary (dircolors, FWIW, pkg=coreutils), and upon investigation and filing a bug suggesting to test that it was a symlink, not the actual binary removed, the maintainer (vapier) decided that the reason that particular post-install quirk was there was far enough back in history he could just remove it from the ebuild. I didn't check whether he removed it from stable, but at least leading ~arch coreutils doesn't have that quirk any longer, and leaves dircolors alone. FWIW, https://bugs.gentoo.org/show_bug.cgi?id=509596 The only other relatively minor irritation that remains is a portage bug, but as I said it's relatively minor as it doesn't affect functionality. But what it /does/ mean is that for nearly EVERY package upgrade, I have an identical message complaining about /usr being a possibly stale symlink, with no easy/apparent way to quite the warning using UNINSTALL_IGNORE, as I can and have with other symlinks such as /var/run -> run, etc. When it stops being a relatively minor irritation and gets big enough to really annoy me (if simply mentioning it here doesn't get it fixed before I actually get to that point), I'll file a bug on it and I expect that annoyance will go away as well. =:^) -- 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
