On Sat, 4 Dec 2004, Andreas Jochens wrote: > However, I had severe problems with 'glibc' upgrades when the '/lib64' > symlink was created by 'glibc' instead of 'base-files'. > Basically, everything stopped working during the upgrade because > the '/lib64' temporarily disappeared and the binaries could not > find the dynamic linker anymore.
If glibc, which contains all the essential libraries and it's in the best position to do it, have problems creating the symlinks, imagine the *huge* mess that might happen if we finally put the symlinks in base-files and we want to remove it later for multiarch support, considering that base-files and glibc do not have any sort of "sync" between them. That is my main objection for putting the symlinks in base-files. Could you please provide details about the problem of having the symlinks in glibc? Is it that glibc has a versioned Replaces: base-files and dpkg removes the symlink in base-files before installing the one from glibc, creating a big window during which /lib64 does not exist at all? In such case I think it would be completely acceptable that the preinst simply manipulates /var/lib/dpkg/info/base-files.list to remove the /lib64 entry from it, so that the Replaces becomes innecessary. I believe dpkg should not have problems installing a symlink when the symlink already exists in the filesystem and does not belong to any package. Sure, it would be a hack, but if the symlink is in base-files, it could be that we need a much bigger hack to remove it later, or worse, it could be that we are in a dead-end and there is no possible hack for the multiarch transition. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
