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
