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
