[gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe?

[Duncan <1i5t5.duncan@cox.net>]

Zac Medico posted on Fri, 31 May 2013 22:49:02 -0700 as excerpted:

> On 05/31/2013 10:36 PM, Duncan wrote:
>> As in subject, is portage bin/usr-bin merge safe?
>>
>> It appears most of my clashing files are /usr/bin/* -> /bin/* symlinks.
>> (That's just bin, I've not looked at sbin.)
> 
> I haven't tried it, but it should work just fine. Portage has always
> supported directory symlinks like these. I haven't heard any recent
> complaints regarding them.

As the attribution says, I'm resurrecting a thread from 2013...

I set up a merged /usr/bin -> /bin (and sbin -> bin, and /usr -> .) soon 
after that, with very few problems, usually ebuilds doing unconditional 
rms in postinst or the like, until recently...

[I'll likely file this as a bug as well, but thought I'd post a followup 
to the old thread here, first.  I'm kinda busy troubleshooting the 
unrelated bug that triggered the coreutils expression of this bug for me, 
ATM.]

Something recently changed, as now I'm having many more problems, so far 
with four packages, glibc (!!), coreutils (!!), nano, and shadow, 
installing symlinks that ultimately point to themselves.  The glibc one 
is of course critical as it breaks pretty much the entire system right 
away, the coreutils set is critical due to the number of frequently used 
binaries it breaks, and I'm lucky I discovered nano before needing it as 
a low-dep fallback editor.  Being a single-user system I don't so often 
use passwd, but like nano, it's one of those things that when it's 
needed, it's REALLY needed.

From my current installmask file:

# 2017.1112 glibc: libm-2.*.so due to /usr -> . symlink,
# symlink overwrites the lib it points to!
INSTALL_MASK="
        $INSTALL_MASK
        /usr/lib64/libm-2.*.so
"

# 2017.1207 coreutils symlinks that overwrite their binaries
INSTALL_MASK="
        $INSTALL_MASK
        /usr/bin/basename
        /usr/bin/chroot
        /usr/bin/cut
        /usr/bin/dir
        /usr/bin/dirname
        /usr/bin/du
        /usr/bin/env
        /usr/bin/expr
        /usr/bin/head
        /usr/bin/mkfifo
        /usr/bin/mktemp
        /usr/bin/readlink
        /usr/bin/seq
        /usr/bin/sleep
        /usr/bin/sort
        /usr/bin/tail
        /usr/bin/touch
        /usr/bin/tr
        /usr/bin/tty
        /usr/bin/uname
        /usr/bin/vdir
        /usr/bin/wc
        /usr/bin/yes
"
# 2017.1207 shadow, nano symlinks
INSTALL_MASK="
        $INSTALL_MASK
        /usr/bin/nano
        /usr/bin/passwd
"

So what changed in portage that previously prevented the /usr/* symlinks 
from overwriting the non-usr binaries, but now allows the overwrites to 
go ahead, breaking the system?

Note that I ran into the glibc library symlink issue first.  I ran into 
the coreutils issue after a bad upgrade (unrelated, I think) broke X, 
forcing me back to a backup and I started upgrading a few packages at a 
time from binpkg, to see which one broke X again.  When I got to 
coreutils, the qmerge phase broke half way thru as a binary was replaced 
by a symlink to itself.  I'm not sure why it triggered in binpkg install 
but not when I had originally installed it on the system, but it may be 
due to the fact that I normally run parallel merges so the system is 
heavily loaded during normal merge, while with the binpkg merge it 
wasn't, thus implying a race condition of some sort.  I discovered the 
nano and shadow/passwd issues, seeing their binaries were broken symlinks 
to themselves, when fixing the coreutils issue. I've no idea when they 
happened.

-- 
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