Bug#50832: AMENDMENT] Clarify meaning of Essential: yes
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 \
` firstname.lastname@example.org - email@example.com - firstname.lastname@example.org '