On Wed, Aug 10, 2011 at 03:05:19PM -0500, Jonathan Nieder wrote: > Aug 10, 2011 at 09:59:48PM +0200, Aurelien Jarno wrote: > > On Wed, Aug 10, 2011 at 02:50:46PM -0500, Jonathan Nieder wrote: > > >> mv -fT /lib64.eglibc-tmp /lib64 > >> > >> should work. > > > > No it doesn't work for symlinks. > > Could you elaborate? Running > > ln -s a b > ln -s c d > strace mv -fT b d > ls -l d > > seems to suggest replacing one symlink by another works on Linux. > Further, rename(2) is documented to allow this, and I am not aware of > any special-case logic in coreutils that would affect it.
Ah ok, I thought you were trying to replace a symlink by a directory. > [...] > >> rm /lib64 > >> mv /lib64.real /lib64 > >> > >> when nothing is running concurrently, in early boot. > > > > The problem is that your never reboot chroots. > > Sure, hence the need for the admin to intervene at a quiet time (or > it can be left alone --- is a symlink /lib64 -> lib64.real really > harmful?). I don't think we want any manual intervention for this transition. For the symlink I would prefer not having /lib64 left, as a lot of configure scripts are actually looking to /lib64 to determine random things. Also we have just seen that leaving leftover that are not handled by dpkg can be a pain years after. > Alternatively, why can't we keep the /lib64 -> /lib symlink? Getting > rid of it is not my itch. Lack of breakage in the squeeze -> wheezy > upgrade is. Because install libc6:amd64 on a 32-bit system means that /lib64 points to a directory with 32-bit libraries. People can break their systems that way (see for example #632176). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
