On 23 Nov 2006 01:15:28 +0200, Jari Aalto <[EMAIL PROTECTED]> said:
> I would drop that "special" case and always require explicit
> requirement for the shell. It's more clear to see which packages
> "need" bash to make them work. someone may then provide a patch to
> "make bash go away". I suggest removing the last 2 lines:
No, that is a separate discussion. Steve Langasek had an
email where he detailed reasons why one should not depend on
Essential packages; since it prevents moving the essential
functionality to other packages. And it is simple enough to see when
maintainer scripts explicitly use bash; that is far better than
making packages explicitly depend on Essential packages.
This is unlikely to change in the near term, unless there are
compelling arguments to make the dependency explicit (like there is
if a package has a versioned dependency on an Essential
package. Merely makes it easy to see which packages on th4e off
chance that someone manages to make bash go away at some time in the
improbable and remote future is not going to cut the mustard.
> In a way, Policy encourages view that listing explicit
> dependencies is considered bad and wrong. On the contrary The
This is exactly right.
> policy could encourage to make things transparent; this is
> good testing and QA methodology. Policy should not care
> whether package announces all dependencies or that some
> package announces only those not covered in "essential".
I don't think that adding a clutter of Essential packages to
the list of every single package out there adds transparency; it is
clutter, it is redundant; and good QA practice is to abstract away
the common dependency set and make it tacit.
manoj
--
It may be that your whole purpose in life is simply to serve as a
warning to others.
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
