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: