[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#222047: --configure should process essential packages first



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.

essential packages must *always* work.




Reply to: