Re: Bug#30739: When a tiny part of a package uses non-free libraries
On Wed, 16 Dec 1998, Brian Mays wrote:
> Peter S Galbraith <GalbraithP@dfo-mpo.gc.ca> writes:
>
> > As a user, I would expect that _all_ dependencies be listed as such.
> > A _depends_ does not become a _suggests_ because it it's a small part
> > of the package that _depends_ on non-free.
Yes.
> Then what is the purpose of the "Suggests" tag? Why should we have
> multiple levels of dependency? By what you suggest, all we need is
> "Depends" and "Pre-Depends" because no dependency should ever be as
> trivial as "Recommends" or "Suggests."
See below.
> First consider this question: what is a package?
>
> A package is a collection of files that all work together to provide
> some service or feature to the system. Like virtually everything else
> in computer science or engineering, it is a compromise. We could use
> a system to track each file and arrange dependencies on a per-file
> basis, but such a system would be unwieldy, to say the least. We also
> could use a system that divides the operating system into a few broad
> categories, much like our sections, with each category being a package.
> Such a system, however, would not be as flexible for choosing exactly
> what software is installed and would not be as easy to use for upgrades
> as new versions of the upstream sources are released.
Indeed.
> The way Debian is set up, each package has a purpose. When I install
> the pcmcia-cs package, I expect it to meet its advertised purpose, that
> is, to allow my system to access its PCMCIA cards.
Yes. You may also assume that any program that is in the package actually
works.
> Now ask yourself: why does Debian have three levels of dependency and
> what do they mean?
>
> Debian has three levels of dependency because different parts of the
> package (the individual files) are more or less important to meeting
> the package's primary purpose. Thus, items marked "Depends" are
> absolutely essential for the package to fulfill its purpose; it cannot
> do what it needs to do without these additional packages. Items marked
> "Recommends" are required for the package to meet its purpose, but some
> sort of reduced functionality is possible without them. Therefore,
> dpkg can install (without a manual override) a package when some of its
> recommended packages (i.e., listed under "Recommends") are missing.
>
> And what about "Suggests?" Is it some sort of fancy, automated package
> referral system? (As in: "If you like this bit of software, try package
> foo; it's really cool.") Absolutely not! (Although some package
> maintainers seem to use it this way.) The real meaning of "Suggests"
> is the following: the package already fulfills its purpose, but EXTRA
> functionality is possible if you install the packages listed here.
This is a very wrong viewpoint of the use of the three depencency levels,
and it is definitely not how they are used in Debian.
If any program in package A requires anything that is in package B, it
must have a 'Depends:' for package B. This is why packages depend on
packages such as libc6 and other lib* packages and it also the reason why,
for example, the tetex-extra package depends on the tetex-base package.
If every program in package A can work without package B being installed,
but the practical functionality would be minimal, package A can have a
'Recommends:' for package B. For example, the procmail package recommends
'smail | sendmail | mail-transport-agent | fetchmail' (the pipe symbols
mean 'OR') and the tetex-bin package recommends the tetex-extra package.
dpkg doesn't care about these recommendations, but dselect treats them
like 'real' dependencies.
If package A will be fully functional without package B, but the package
maintainer of package A thinks that most people who install package A will
also need package B, package A can have a 'Suggests:' for package B. For
example, the tetex-extra package suggests the tetex-nonfree package and
the lprng package suggests magicfilter and lprng-doc. Many packages that
have a separate '-doc' package suggest the '-doc' package.
> > However, it's true that we don't strictly list all dependencies
> > which would make the contents of a package useful. For example, We
> > may include html docs without _depending_ on a web browser. We may
> > include an emacs mode and only _suggest_ emacs.
>
> Considering what I have written above it is clear why we do this in
> practice. The documentation, be it in html, info, or roff format, is
> irrelevant to the package's task of fulfilling its purpose. Of course,
> reading the documentation to know how to configure and operate the
> software is assumed to be obvious and not deemed worthy of a dependency.
Yes. That's why dependencies are about programs, not documentation.
> > But in this case, where it's about a binary, I'd argue you can't
> > include even a small binary that depends on non-free withiout listing
> > that dependency (which would put the whole thing into contrib). The
> > quick fix is to split the package.
>
> See my other message in this thread for my arguments against unnecessary
> package fragmentation.
>
> To summarize and clarify, cardinfo comes from the same source as and
> provides extra functionality to the rest of the pcmcia-cs package.
> There is absolutely no reason to install cardinfo onto a system unless
> the rest of the pcmcia-cs package is also there. Furthermore cardinfo
> is small, and the costs in overhead of splitting off all such small
> "extra" programs outweighs any advantage provided by the split (see
> my comments above about the packaging system being a compromise).
> Therefore, I do not think that cardinfo is worthy of its own package.
It's the maintainer's choice. Either spilt off cardinfo and put that in
contrib (or leave it out, for that matter), or move the whole package into
contrib.
> > Sorry Brian, but that is my very humble opinion (even if I greatly
> > appreciate your packaging of pcmcia-cs). We should be adamant that
> > `main' should be about _free_ software; cardinfo isn't.
>
> Thank you. It's always nice to be appreciated, but cardinfo is free.
> Unfortunately, the xforms library is not.
Yes. And the rule is that anything that is free but depends on something
non-free goes into contrib.
> What I have written here is my opinion and expresses my understanding
> of how Debian's packaging system and dependencies work. If I have
> misinterpreted either, please explain my errors.
One of the main rules in Debian is, that _every_ package in main can be
built from the source packages in main. Programs that need non-free
libraries break this rule, so packages containing programs that need
non-free libraries CAN NOT be in main.
Remco
Reply to: