Re: Ordering
On 9 Mar 1998, Manoj Srivastava wrote:
> Unpacking ordering different from configuration handling does
> nt allow packages to be useable earlier. It just makes it hard to
> handle Essential packages and other configure now stuff.
Actually configure now are just handled by considering dependancies when
ordering, this promotes those dependancies to a critical level [meaning
loops are fatal]. That is what is done for predepend. You have said
yourself that in a few cases pkgorder DOES create an order that results in
a package being unpacked but unconfigurable, and I know this happens
frequently when handling removals (unless you wish to force remove!)
I do agree that configure now and configure now for essential + essential
depends is more important than this rule, but it doesn't mean we cannot
have both.
> I think I prefer the invariant: No package is ever unpacked
> when It can not be configured.
I am certain this is unachievable for all cases - this is because you
cannot immediately configure all packages (ie libpaper, the Chimera Case,
etc).
> So one may interrupr the unpacking process, and just say
> configure --pending and have things work.
This is NOT TRUE! Remember dpkg does not check reverse depends when
configuring, so if in the chimera example you did:
inst xlib6
-- ABORT!!
inst chimera
and then did dpkg --configure -a and then tried to run dpkg-get it would
say
Checking sytem integrity.. ERROR!
E: The package chimera is broken.
And not allow you to continue. With the other ordering dpkg will
correctly leave chimera unconfigured and this situation will not arise.
If dpkg was fully working then --configure --pending should result in
either xlib6 not being configured or in chimera being deconfigured, which
is the state things would be left in by the alternate order.
Like you said, do not confuse what dpkg allows with what is desirable.
Jason
Reply to: