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