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

[Zac Medico]

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