Subject: Re: dpkg and dependencies - manual update

From: Ian Jackson <[email-masked]>
Date: Wed, 11 Sep 96 23:42 BST

Thanks, Guy, for clarifying that issue.  I've added the following to
the programmers' manual:
> When selecting which level of dependency to use you should consider
> how important the depended-on package is to the functionality of the
> one declaring the dependency.  Some packages are composed of
> components of varying degrees of importance.  Such a package should
> list using <tt/Depends/ the package(s) which are required by the more
> important components.  The other components' requirements may be
> mentioned as Suggestions or Recommendations, as appropriate to the
> components' relative importance.

Ian.

---

From: Dale Scheetz <[email-masked]>
Date: Thu, 12 Sep 1996 09:19:29 -0400 (EDT)

> > components' relative importance.
For me, this is still inadequate. Subjective phrases like "components
of varying degrees of importance" and "required by the more important
components" do not lead all readers to the same conclusions. This
importance of the components depends on the goals of the user. Thus, I
find dpkg-buildpackage to be as important to me as dpkg and don't find
dselect to be very important at all. (I realize that this is my personal
point of view, and not shared by all others)
It has been my understanding that the dependency feature of the package
installation software is intended to provide the user with an installation
where all functionality provided by a package will work when the package
has been properly installed (with it's dependency requirements met first).
The relative importance of the various functional components is irrelevant
to this issue, since this is purely subjective. If some functionality is
provided by a package, some indication of the other packages that are
necessary for it's proper operation is absolutely necessary.
If a bit of functionality is so unimportant as to not require reporting of
it's dependencies then why was it included in the package in the first
place?
I have been thinking about a possible dependency problem with Pine. Pine
uses ispell to do it's spell checking. If ispell is not properly
installed, Pine complains, but does so in a way that provides no
information to the user about what the problem is. (The error messages are
pushed off the screen so fast as to be unreadable. The last message that
appears is "Spell checking complete")
For me (heavily spelling impaired) the spell checker is an absolute
necessity. For others it may be totaly unnecessary. How do I determin
which level of depends to use (if any)?

Help me decide which is correct by sending your suggestion via private
e-mail. I will summarize the vote back to the list so we can see just how
much consensus can be had on this kind of issue.

Thanks,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: "Susan G. Kleinmann" <[email-masked]>
Date: Thu, 12 Sep 1996 13:38:35 -0400

Ian Jackson wrote:
> > one declaring the dependency.

Dale Scheetz wrote:
>components" do not lead all readers to the same conclusions.

Actually, it was Raul Miller who clarified the issue for me, when he wrote:
>Package dependencies are a rather crude mechanism, only useful for
>preventing the most blatant configuration mistakes.

I had previously been under the impression that the Debian packaging 
mechanism was meant to be completely self-contained.  No qualitative
evaluations, no fuzziness.

I presume that Raul's description accurately portrays the packaging system 
as having a more limited set of goals.  In that case, while the system may be 
viewed as a vast improvement over other packaging systems which exist
at present (e.g., anything Microsoft offers), it nonetheless has room 
for improvement.  Whether that improvement will happen as part of this 
project or another remains, of course, to be seen.

Susan Kleinmann