[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#632682: base-files: please provide a /lib64 -> /lib symlink on 64-bit systems

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
aurelien@aurel32.net                 http://www.aurel32.net

Reply to: