Bug#259302: Patch update against base-files 3.1
On Mon, 6 Dec 2004, Goswin von Brederlow wrote:
> Kurt Roeckx <Q@ping.be> writes:
> > Preparing to replace libc6-dev 2.3.2.ds1-18 (using .../libc6-dev_2.3.2.ds1-19_amd64.deb) ...
> > Unpacking replacement libc6-dev ...
> > Preparing to replace libc6 2.3.2.ds1-18 (using ..././libc6_2.3.2.ds1-19_amd64.deb) ...
> > Unpacking replacement libc6 ...
> > dpkg - warning, overriding problem because --force enabled:
> > trying to overwrite `/lib64', which is also in package base-files
>
> Does libc6 replace base-files?
Most probably, not. A Replaces: field would produce different messages.
It seems --force-overwrite is enabled by default on amd64. You are lucky :-)
> > Now I just need to be sure how to package this properly so
> > nobody has problems updating libc6 and base-files at the
> > same time. Any hint welcome.
> >
> >
> > Kurt
>
> I was thinking about that and noticed some problem. I haven't checked
> the docs or source yet so this is from memory:
>
> When dpkg updates base-files and libc6 at the same time (and
> even when base-files predepends on libc6) the following happens:
>
> - base-files and libc6 control.tar.gz is unpacked and preinst is run.
>
> - base-files and libc6 data.tar.gz each are unpacked and obsolete
> files are removed. The order can be either way and if base-files is
> first we are screwed.
>
> - libc6 is configured.
>
> - base-files is configured.
>
> So the problem is the second step. Is my memory right there or does
> dpkg first unpack all debs and only then remove obsolete files?
PreDepends are stronger than Depends. If you upload a base-files
version which Pre-Depends on the libc6 that contains /lib64, then such
libc6 should be unpacked *and* configured first.
Unfortunately, removing /lib64 in the preinst does not seem to work
(I've just checked).
Instead, you probably need a base-files version which *contains* /lib64
in the .deb but removes it from base-files.list in the postinst
(not the preinst).
> I fear removing the /lib64 from base-files.list in preinst could be
> neccessary. Just till every amd64 user has updated.
Yes, some hacks will have to be there for some time.
It could be like this:
a) A new base-files removes /lib64 from base-files.list in postinst.
b) Wait until everybody has upgraded.
c) Upload libc6 containing /lib64.
d) Remove /lib64 from base-files, or just remove the special amd64
base-files version and use the ordinary one, which does not contain /lib64.
Upgrading from the version which removed /lib64 from its .list should
be safe.
So, I think it would be better if base-files stops claiming ownership
over /lib64 ASAP, before the symlink is added to libc6.
Then there is the problem of new installs (debootstrap). I think the
above plan would work for new installs as well.
Reply to: