Bug#259302: Patch update against base-files 3.1
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.
Reply to: