Control: retitle -1 dpkg: Provide an interface for bootstrapping an installation
Hi! On Sun, 2003-11-23 at 16:44:37 +0100, Koblinger Egmont wrote: > Package: dpkg > Version: 1.10.18 > Currently if more unconfigured packages are being configured, their > ordered is determined by the Depends fields of the packages, however, the > Essential field is not taken into account, hence it might (and actually > does) occur that a non-essential package is configured earlier than an > essential one. > > This behaviour is against the policy that AFAIK essential packages > required by a certain package do not need to be explicitely mentioned in > the Depends field. Just one example: on a Debian 3.0 system nscd only > depends on libc6, even if its startup script requires bash, shellutils > (uname), grep and dpkg (start-stop-daemon), but these are all essential > packages. > > On a dpkg based (but not Debian) system I have a script that builds up a > chroot system: it unpacks all the required .deb files to a directory, and > later it runs "dpkg --root=... --configure -a". In most of the cases it > runs perfectly. However, I've met the following interesting situation: > building up the chroot failed if I put postgresql-server amongst the > packages. postgresql-server invokes a "su -c command otheruser" command in > its postinst script. However, su requires valid basic configuration, which > isn't available as long as shadow (and possibly some other essential) > packages are unconfigured (e.g. /etc/shells might not yet be present). The > "dpkg --configure -a" step just randomly chose to configure > postgresql-server earlier than shadow, and hence it failed. Obviously > making postgresql-server depend on shadow solved the problem, but since > shadow is an essential package, I expect that it shouldn't be necessary to > mention it in postgresql-server's Depends field, I think the postinst > script of a non-essential package could expect that essential packages are > already configured. > > So whenever more packages are being configured, essential ones should be > processed first, before any non-essential ones. As Santiago mentioned, you are describing here an installation bootstrapping problem, so the problem you encounter should only ever happen when the system is not yet in place, and the Essential semantics have no meaning yet (because the Essential packages have never been configured once). This is all in a different realm where the behavior is currently unspecified. Also your proposal is not general enough, as that does not cover implicit dependencies between Essential packages, before they have been bootstrapped. A proposed solution to this can be found at <https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap>. Thanks, Guillem
