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.
[...]
>> 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?).
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.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
