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

[Zac Medico <zmedico@gentoo.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4085 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 224 bytes --]