On Sun, 5 Dec 2004, Kurt Roeckx wrote: > On Sun, Dec 05, 2004 at 04:39:06PM +0100, Santiago Vila wrote: > > > > 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? > > glibc (libc6) does not replace base-files. Why should it?
Because otherwise the upgrade from an already running amd64 system (which has a modified base-files containing the symlink) would result in dpkg complaining about a file conflict. A Replaces field would allow dpkg to move the ownership of the symlink from base-files to libc in a clean way. However, it there is a time window during which /lib64 does not exist at all it will not work that way. I think that dpkg replaces files from a package with files from the same package (when upgrading it) in an atomic way, it's a pity that it does not seem to do the same for files affected by a Replaces which are moved from one package to another one. I agree that the preinst hack would not be very nice. You could also hack base-files itself (only the amd64 version in the amd64 archives) so that it removes /lib64 from /var/lib/dpkg/info/base-files.list in its preinst at the same time it does no longer ship /lib64 inside the .deb. Then /lib64 would still exist but it would not be "owned" by base-files. After this, libc6 will not need the hack. Then, after libc6 takes care of the symlink, the special version of base-files that contains the symlink could be removed from the amd64 archives so that the usual base-files version is used instead for new installs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
