Re: dpkg, ELF, upgrade order, broken systems
I think your proposal is rather kludgy. I don't think it is justified to
introduce a new field in the packaging database for using in a very
specific (although important) problem which will not repeat in the future.
I would prefer to have an "elf-update.deb" package whose content would be:
libc5 libraries (/tmp/libc5.deb)
new ld.so (/tmp/ldso.deb)
new dpkg (/tmp/dpkg.deb)
new kernel (/tmp/linux???.deb)
some other critical package? (/tmp/critical-package.deb)
This is a sketch, of course. I mean having a .deb whose content is the
critical .deb packages. It would place them in /tmp. Then a postinst
script would run dpkg -i /tmp/package in the _right_ order:
dpkg -i /tmp/first.one.deb
dpkg -i /tmp/second.one.deb
...
rm /tmp/first.one.deb /tmp/second.one.deb ...
Is that clear?
My solution is kludgy too. However, it does not need cooperation from
many developers, it does not include unnecessary fields in everyone's
packages database, it is much more customizable and it is closer to
Debian's philosophy of doing the hard work through well designed
installation scripts.
We only need a volunteer to make the "upgrade-to-elf.deb" package.
Anyone?
On Mon, 22 Jan 1996, Ian Jackson wrote:
> I propose to introduce a new feature into dpkg shortly. It will
> hopefully make it much harder to break your system while attempting an
> ELF upgrade.
>
> The feature will be invoked by a `Pre-Depends' control file line,
> which has the same syntax as a Depends line. The effect will be for
> dpkg to refuse to unpack a package if the pre-dependency is not
> satisfied.
>
> Usually a dependency is only considered satisfied if the depended-on
> package is both installed and configured; a pre-dependency will be
> also considered satisfied if the depended-on package is unpacked or
> half-configured, provided that it was previously properly configured.
> If the pre-dependency includes a version specification then both the
> version installed and the previously-configured version must satisfy
> the version specification.
>
> This can be used by base packages which need the new ELF libc (so that
> your ls, bash or dpkg doesn't get replaced by an ELF version until the
> libc and ld.so are installed), or by any package which needs features
> from a particular dpkg version.
>
> IT SHOULD NOT BE USED BY ANY OTHER PACKAGES. This is because it
> imposes an installation order, which is complicated to deal with for
> dselect methods and users.
>
> The Pre-Depends line will appear in the Packages files, where dselect
> methods can use it to ensure that the packages are fed to dpkg in the
> right order (though support for this may be a little while coming).
>
> There will be a `dpkg --assert-pre-depends' option, which packages
> using Pre-Depends should use in their preinst so that the installation
> will fail if an insufficiently early dpkg version is used.
>
> Comments, anyone ?
>
> If not then I'd appreciate it if base packages started having
> Pre-Depends lines added; we can add the --assert-pre-depends later.
>
> Ian.
>
>
Reply to: