From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id DD6C2139083 for ; Thu, 7 Dec 2017 09:07:27 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 195ECE0FC5; Thu, 7 Dec 2017 09:07:26 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CE74DE0EC6 for ; Thu, 7 Dec 2017 09:07:25 +0000 (UTC) Received: from [192.168.0.15] (ip68-4-233-67.oc.oc.cox.net [68.4.233.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: zmedico) by smtp.gentoo.org (Postfix) with ESMTPSA id D3DED33BF51; Thu, 7 Dec 2017 09:07:24 +0000 (UTC) Subject: Re: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe? To: gentoo-portage-dev@lists.gentoo.org, Duncan <1i5t5.duncan@cox.net> References: <51A98B4E.8090601@gentoo.org> From: Zac Medico Message-ID: <6c2ee2b3-88df-e943-61d5-d1e846789ab1@gentoo.org> Date: Thu, 7 Dec 2017 01:07:21 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="S8DxohKo3eFxsPx8wA0AoHQsArSs5oAtE" X-Archives-Salt: da11f164-3a48-4544-b5d6-83734cd79c44 X-Archives-Hash: 38296eeb703c5a5e10a3cfca92bbec4f This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --S8DxohKo3eFxsPx8wA0AoHQsArSs5oAtE Content-Type: multipart/mixed; boundary="eSXqeggopDTxj3KTL5Aroi3e2cP36XkIm"; protected-headers="v1" From: Zac Medico To: gentoo-portage-dev@lists.gentoo.org, Duncan <1i5t5.duncan@cox.net> Message-ID: <6c2ee2b3-88df-e943-61d5-d1e846789ab1@gentoo.org> Subject: Re: [gentoo-portage-dev] Re: Is portage (/usr)/bin-merge safe? References: <51A98B4E.8090601@gentoo.org> In-Reply-To: --eSXqeggopDTxj3KTL5Aroi3e2cP36XkIm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 12/07/2017 12:37 AM, Duncan wrote: > Zac Medico posted on Fri, 31 May 2013 22:49:02 -0700 as excerpted: >=20 >> 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/* symlink= s. >>> (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. >=20 > As the attribution says, I'm resurrecting a thread from 2013... >=20 > I set up a merged /usr/bin -> /bin (and sbin -> bin, and /usr -> .) soo= n=20 > after that, with very few problems, usually ebuilds doing unconditional= =20 > rms in postinst or the like, until recently... >=20 > [I'll likely file this as a bug as well, but thought I'd post a followu= p=20 > to the old thread here, first. I'm kinda busy troubleshooting the=20 > unrelated bug that triggered the coreutils expression of this bug for m= e,=20 > ATM.] >=20 > Something recently changed, as now I'm having many more problems, so fa= r=20 > with four packages, glibc (!!), coreutils (!!), nano, and shadow,=20 > installing symlinks that ultimately point to themselves. The glibc one= =20 > 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 use= d=20 > binaries it breaks, and I'm lucky I discovered nano before needing it a= s=20 > a low-dep fallback editor. Being a single-user system I don't so often= =20 > use passwd, but like nano, it's one of those things that when it's=20 > needed, it's REALLY needed. >=20 > From my current installmask file: >=20 > # 2017.1112 glibc: libm-2.*.so due to /usr -> . symlink, > # symlink overwrites the lib it points to! > INSTALL_MASK=3D" > $INSTALL_MASK > /usr/lib64/libm-2.*.so > " >=20 > # 2017.1207 coreutils symlinks that overwrite their binaries > INSTALL_MASK=3D" > $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=3D" > $INSTALL_MASK > /usr/bin/nano > /usr/bin/passwd > " >=20 > So what changed in portage that previously prevented the /usr/* symlink= s=20 > from overwriting the non-usr binaries, but now allows the overwrites to= =20 > go ahead, breaking the system? >=20 > Note that I ran into the glibc library symlink issue first. I ran into= =20 > the coreutils issue after a bad upgrade (unrelated, I think) broke X,=20 > forcing me back to a backup and I started upgrading a few packages at a= =20 > time from binpkg, to see which one broke X again. When I got to=20 > coreutils, the qmerge phase broke half way thru as a binary was replace= d=20 > by a symlink to itself. I'm not sure why it triggered in binpkg instal= l=20 > but not when I had originally installed it on the system, but it may be= =20 > due to the fact that I normally run parallel merges so the system is=20 > heavily loaded during normal merge, while with the binpkg merge it=20 > wasn't, thus implying a race condition of some sort. I discovered the = > nano and shadow/passwd issues, seeing their binaries were broken symlin= ks=20 > to themselves, when fixing the coreutils issue. I've no idea when they = > happened. >=20 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 --=20 Thanks, Zac --eSXqeggopDTxj3KTL5Aroi3e2cP36XkIm-- --S8DxohKo3eFxsPx8wA0AoHQsArSs5oAtE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHEEARECADEWIQSG5RNTeMgVEruefzL96O+FrlcZowUCWikEyhMcem1lZGljb0Bn ZW50b28ub3JnAAoJEP3o74WuVxmji+IAmgJVHJmdN6Kkt2tmrkrKMy1w/cNwAKDl dZXalCipv27VaLQCnro7ZZnN8A== =N/5W -----END PGP SIGNATURE----- --S8DxohKo3eFxsPx8wA0AoHQsArSs5oAtE--