[gentoo-dev] Re: Making a common sub-profile for no-multilib

[Duncan]

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