Re: Bug#30739: When a tiny part of a package uses non-free libraries
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.
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."
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.
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.
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.
> 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.
If a special emacs mode is included in the package (assuming that the
purpose of the package was not to provide this special mode), then this
additional component provides extra functionality. It is not essential,
does not have to be used, and therefore scores emacs a "Suggests"
dependency.
> 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.
> 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.
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.
Brian
Reply to: