On Wed, Dec 08, 1999 at 10:22:02AM -0500, Ben Collins wrote:
> For example, if gzip (for some reason) becomes unusable until after it is
> configured, then we have to remove its essential flag (according to this
> proposal). Can you guess how many packages will now have to depend on it,
> or better yet, which ones specifically?
Well, dpkg for a start. (Even the instance currently running, probably)
I don't really think this is a major issue --- I can't think of anything
that can't be adequately configured by the time it's unpacked, assuming
you're willing to be a little kludgy. (the filesystem can be arranged
just by including everything in the .deb; and running processes can be
arranged by just keeping the old daemons running over the upgrade, eg)
And more to the point, everything /does/ already work like that, so we
can just be resistant to any upstream changes that cause that to fail :)
The --force- option would have a couple of (resolvable?) problems, though.
It'd break all the dselect methods that use -iGROEB, for a start ---
since that wouldn't be able to upgrade essential packages any way but
individually. I suspect rewriting dpkg to do installation ordering would
be... painful. It'd also impose an extra ordering constraint on apt (as
opposed to breaking it). Admittedly, that constraint's already satisfied,
but still. The fewer dpkg invocations the better.
Unless you're planning on doing the freaky new interface to dpkg, that
lets Apt tell it when to configure packages? :)
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpoDbNPdtabu.pgp
Description: PGP signature