Subject: dpkg and dependencies

From: "Susan G. Kleinmann" <[email-masked]>
Date: Thu, 05 Sep 1996 10:20:46 -0400

Ian Jackson and I have had several exchanges by private email 
having to do with the dependencies in dpkg, following my bug reports:
#4262 (dpkg-source requires cpio) and #4263 (dpkg-source requires patch).

We have now come to an impasse.  Ian suggested if I were to bring this
to debian-devel "perhaps someone there will set you straight."

Here are the arguments:

I> cpio is only required by dpkg-source, and not to install packages.

I> I've added it to Suggests and mentioned it in the Description.  This
I> will be in 1.3.10.

   (ditto for patch.)

S> Now I'm confused.  I would have thought that since a command within the
S> dpkg package requires cpio in order to operate, that the whole dpkg package
S> would be said to "Depend" on cpio.  

I> No.

S> This is not my reading of the programmer's manual, which says:
S> "Suggests:
S> This is used to declare that one package may be more useful with one
S> or more others.  Using this field tells the packaging system and the
S> user that the listed packages are be [sic] related to this one and can
S> perhaps enhance its usefulness, but that installing this one without
S> them is perfectly reasonable."

I> The manual is correct.  I believe dpkg is in accordance with it now.

S> It is unreasonable to install software (dpkg-source) which won't 
S> function at all without additional files.  

I> So are you suggesting that I should split dpkg up into half a dozen
I> packages ?  Since debian-changelog-mode.el won't work without Emacs I
I> have to make dpkg depend on Emacs ?  Since you can't use
I> dpkg --print-architecture to determine the build architecture unless
I> you have GCC and libc installed I should make dpkg depend on those ?
I> Since dpkg's NFS installation method won't work without NFS loaded
I> into the kernel I should refuse to allow dpkg to install properly if
I> you don't have that configured in ?

S> Yes.

S> In any case, what is the mechanism to warn the user that only 1 
S> (or perhaps 0, 2, or some other number) of components of a package 
S> he's got installed ought to be expected to work?

I> Suggests, plus the Description, and the manuals for the package
I> components if this is thought necessary.

S> I find this logic absurd.  If it is "reasonable" to install software that
S> won't work, then what is the reason?  Just to remind oneself of its
S> existence?  

S> Debian users should be told during the initial installation they will
S> have 2 choices:
S> -- realize that some, most, or perhaps all of the software they just 
S>    thought they installed won't work at all, and that they'll need to read 
S>    every doc and every man page and every info page associated with the 
S>    package in order to identify the components that won't work, or 
S> -- follow religiously every suggestion made by every package.

S> I doubt this is the common understanding of the word "suggests", except
S> perhaps in the world of organized crime.

S> The package dependency mechanism does little good if there is not a common
S> understanding and use of it.

OK, will someone please "set me staight"?

Susan Kleinmann

---

From: Guy Maor <[email-masked]>
Date: Thu, 5 Sep 1996 13:42:27 -0500 (CDT)

> S> them is perfectly reasonable."

I use the word dependency in the general sense - to refer to Depends,
Recommends, Suggests, and Pre-Depends.

The crux of your disagreement is how you define dependencies between
packages.

Susan argues that a package is composed of individual files.  A
package's dependency is the least restrictive dependency which fulfills
all the files' dependencies.

Ian argues that a package is composed of files of varying degrees of
importance.  A package's dependency is the dependency which fulfills
the more important files' dependencies.  The secondary files'
dependencies may be mentioned as Suggestions or Recommendations based
on their relative importance.

The more important files are those which provide the package's
functionality to a majority of users.  Unfortunately this distinction
is somewhat arbitrary.

I agree with Ian's definition.  The alternative is unpleasant - a
multitude of tiny packages.  Perhaps a paragraph explaining the
relationship between file dependencies and package dependencies could
be added to the Programmer's Documentation.

Guy

---

From: Dale Scheetz <[email-masked]>
Date: Thu, 5 Sep 1996 14:49:47 -0400 (EDT)

> I> cpio is only required by dpkg-source, and not to install packages.
So? Dpkg-source is a program that will not function without the proper
version of cpio, or patch, or diff. This program, by your own definition
depends on these other programs/packages. Since it is a delivered
functionality of dpkg, it seems only logical that the package should
reflect this dependance.

> I> you don't have that configured in ?

Well, maybe not a half dozen ;-) However, dpkg and dpkg-dev sounds like a
good start. Put all the installation programs, dpkg, dselect, etc, into
dpkg and all the development tools like dpkg-source into dpkg-dev. This
should make it clearer to you that dpkg-dev does, in fact, depend on the
packages in question. WRT the emacs piece, this is not a program, but a
thing (script?) that emacs can run to look at dpkg files and as such
represents "enhanced" functionality, so at the most, it might need to
appear in the suggests list. On the other hand, if one of the programs
providing functionality in the package actually needs this file to
operate, then yes, emacs should be in the dependancy list.

Luck,

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: Juergen Menden <[email-masked]>
Date: Fri, 6 Sep 1996 15:04:54 +0200 (MET DST)

On Thu, 5 Sep 1996, Guy Maor wrote:
> 
> [very helpful description of dependencies deleted]
> I agree with Ian's definition. 

me to. :-)

> The alternative is unpleasant - a multitude of tiny packages.  

nevertheless dpkg should be divided into two binary packages:
dpkg (which is the most esential base package of all :-), and
dpkg-source, which only the developers will want to have.

this way the dependencies (while different) could eventually 
become simpler?

jjm

-- 
Juergen Menden                   | Disclaimer: The opinions expressed by me, 
tel:    +49 (89) 289 - 22387     +-----------+ are (usually) not the opinions 
e-mail: [email-masked]     | of anyone else on this planet.

Hi! I'm a .signature virus!  Add me to your .signature and join in the fun!