On Thu, Dec 09, 1999 at 12:38:56AM +1000, Anthony Towns wrote: > On Wed, Dec 08, 1999 at 09:33:30AM -0500, Ben Collins wrote: > > > > > + Since dpkg will not prevent upgrading of other packages > > > > > + while an <tt>essential</tt> package is in an unconfigured > > > > > + state, all <tt>essential</tt> must supply all their core > > > > > + functionality even when unconfigured. If the package > > > > > cannot > > > > > + satisfy this requirement it should not be tagged as > > > > > essential, > > > > > + and any packages depending on this package should instead > > > > > + have explicit dependency fields as appropriate. > > > > Sorry that I missed most of this, but... > > > > I think this will make the dependency chain even more complex. I agree > > > It doesn't actually do anything, it just documents existing caveats. > > Actually it enforces existing caveats. It just seems to be side stepping the > > real problem to me. Changing all the dependencies (removing essential status > > to force other packages to dep on it) just seems like policy juggling, and > > the actual problem is really more technical related. > > Erm. But there *isn't* a problem. > > The only `problem', is that it's not obvious what you ought to be > doing when you're working with Essential packages. As was seen when > Torsten applied my patch to bash and royally screwed it, because /bin/sh > disappeared between bash being unpacked and configured.
So the main issue is making people aware that essential packages need to be in a usable state even when not configured? BTW, do not label this as an official "nay" on this proposal, just an unnofficial enquiry. I don't want my ignorance of this to cause any slowdown in it's acceptance as policy. -- -----------=======-=-======-=========-----------=====------------=-=------ / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
