Aurelien Jarno wrote:
> 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.
Ok, that's convincing enough. I'm tempted to suggest (*)
mkdir /lib64.real
symlink $(readlink -e /lib/ld-linux-x86-64.so.2) to
/lib64.real/ld-linux-x86-64.so.2
if this is a chroot:
sync
unlink /lib64
rename /lib64.real to /lib64
sync
else:
ln -s lib64.real /lib64.eglibc-tmp
rename lib64.eglibc-tmp to /lib64
and replacing the /lib64 symlink with a directory on startup in the
non-chroot case, hoping that
(1) in chroots, hopefully not too much is happening concurrently
(2) in non-chroots, people reboot from time to time to get security
updates
But for now, why not always take the "if this is a chroot" branch.
The atomicity part can happen later (when it is reported as a bug or
someone implements it). If we're lucky, the syncs will stall other
processes long enough to avoid trouble. :)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
