Re: Ordering

[Manoj Srivastava <srivasta@datasync.com>]

Hi,

	Yes, dpkg does indeed behave that way. But we also know dpkg
 is broken in these regards ;-)

	In the Chimera case: Yes, it is nice if we unpack in that
 order: rather than breaking a configured package, we unpack a new
 one, un configured.

	So technically, a configured package did not break. However,
 the package is not working either: it needs be configured. But it
 cannot be confgured yet: we have to wait until other things are
 configred: 

	What have we gained from this? a weak invariant: configured
 packages are unconfigred rather than breaking, but we loose the
 ability to handle configure now packages, since we have unpacked
 stuff we cannot configure yet!

	Can we really use Chimera in the meanwhile? NO.

	I think, therefore, this is a really bad idea (TM).

	BTW, the new release of pkg-order, which is heading out in a
 couple of hours, handles all this. It even handles the perl case.

	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.


	I am currently testing a whole slew of test cases right now (I
 intend to add about a dozen additional ordering tests for
 pkg-order, which shall include the cases you mentioned.) 

	I think we can accept some packages being broken during an
 update. I do not think that that is a rule that has to be held at the
 expense of correctly handling Essentials and other configure now
 packages. 

	I think I prefer the invariant: No package is ever unpacked
 when It can not be configured.

	So one may interrupr the unpacking process, and just say
 configure --pending and have things work.

	manoj
-- 
 Hartley's First Law: You can lead a horse to water, but if you can
 get him to float on his back, you've got something.
Manoj Srivastava  <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E