[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#50832: AMENDMENT] Clarify meaning of Essential: yes



Jason Gunthorpe <jgg@ualberta.ca> writes:

> On 9 Dec 1999, Chris Waters wrote:
> 
> > I'm a little bit afraid that this opens the door to endless debates
> > about what the "core functionality" of a package is.  For example, I
> > would have considered the "core functionality" of the bash package to
> > be providing /bin/bash, but someone was trying to claim that it is
> > providing /bin/sh.

> I don't think this is a real problem - "core functionality" of an
> essential package is all functionality that other packages implicitly
> depend on.

That's simple to refute: I can make a package that implicitly depends
on the bash package having /usr/bin/wish in it.  If we accept your
definition, then that's suddenly not just a bug in my package, but a
bug in bash as well!

Really, what you mean is functionality that other packages are
*allowed* to implicitly depend on.  And that, as I said, opens the
door to endless debates.

> For the essential pacakge providing /bin/sh (aka bash) that
> file is part of the reason it is essential, thus it is a "core
> functionality".

Other packages aren't allowed to assume that /bin/sh points to bash.
(See the many "<foo> is a bashism" bug reports).  And there are other
packages that provide the /bin/sh functionality, and if you have one
of those packages installed, then bash shouldn't *have* to provide
that functionality, and maybe even *shouldn't be* providing that
functionality.  Which was basically the whole point of the exercise in
the first place.

If functionality that a package may *not* be providing is core
functionality, then I think the term "core" is misleading.  Come up
with a better term, and I'd be a lot happier.  Maybe "essential
functionality".  It's still ambiguous, but at least it's not as
confusing.

But in any case, the proposal is redundant.  Causing other packages to
fail is already a bug.  We need a way to deal with situations like
this, where essential functionality is combined with the alternatives
system.  But what we need a technical solution, not more policy.
(What we really need is essential virtual packages, but failing that,
a good workaround would be nice.)

Adding a second reason why some bugs are bugs really doesn't seem to
buy us much.

Furthermore, it occurs to me that the problem isn't just essential
packages.  If libc6 fails to work during an upgrade, we're equally bad
off, but libc6 isn't essential.  So, the proposal is not only
ambiguous and redundant, but misdirected as well.  Only the fact that
it's harmless (because it's redundant) keeps me from formally
objecting.  :-)

cheers
-- 
Chris Waters   xtifr@dsp.net | I have a truly elegant proof of the
      or    xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr     | this .signature file.


Reply to: