On 12/07/2017 12:37 AM, Duncan wrote: > 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. >
I think the sort order of your root directory changed for some reason. The order that readdir returns filenames depends on the filesystem implementation: http://man7.org/linux/man-pages/man3/readdir.3.html -- Thanks, Zac
signature.asc
Description: OpenPGP digital signature