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.
