On Mon, 6 Dec 2004, Goswin von Brederlow wrote: > Kurt Roeckx <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
