On Mon, 1 Dec 2003, Adam Heath wrote: > reassign 222047 shadow > thanks > > On Sun, 23 Nov 2003, 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. > > that's a bug in shadow for not working when unpacked but not configured.
Not necessarily. > essential packages must *always* work. That's not accurate. A better way to express that would be "essential packages must not stop working during upgrades once they have been properly configured for the first time". This seems to be just a bootstrapping problem. I suggest the submitter that he uses deboostrap and either use it directly or copy whatever tricks it uses to ensure that the packages are installed and configured properly in the chroot in the right order.