Re: Library depending on -data packages
On Mon, Mar 21, 2011 at 05:18:00PM +0100, Luca Capello wrote:
> Given that I found this problem for the second time in the last 4
> months, I think this is worth a discussion on debian-devel@.
I agree.
> It seems that recently two library packages started to change their
> Recommends: to common data to a Depends:. This after two bugs were
> reported by the same person, Josh Triplett (cc:ed, sorry for the spam),
I appreciate the CC.
> who asked for an explanation for the Recommends: (a reason which I find
> perfectly valid). The two bugs are:
>
> <http://bugs.debian.org/599643>
> <http://bugs.debian.org/599666>
>
> When I found out about libm17n-0, I also found out that the change added
> a circular dependency and thus commented on this new bug why I think a
> library package should not depend on data packages:
>
> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604926#20>
>
> And now, while looking again for that bug to be linked here, I found
> another occurrence of such a situation, reported almost one year ago [1]
> by Axel Beckert (cc:ed as well, again sorry for the spam):
>
> <http://bugs.debian.org/582797>
>
> [1] I remember that during one upgrade of emacs-snapshot I was surprised
> it pulled anthy-common, but then forgot about reporting it...
>
> I see these situations as a misuse of Depends: where Recommends: would
> be perfectly fine, otherwise Recommends: are useless. But given that it
> seems no one agrees with me, is such a behavior documented somewhere?
Some of these cases might require Depends, and some might require
Recommends. I don't necessarily know why the libraries might need the
data packages, hence my bug reports asking for an explanation for the
Recommends. I still don't know the answer, since the libraries changed
to use Depends rather than documenting the Recommends. :)
If a library really does *require* the corresponding data package in
order to do its job for programs that link to it, then the library
should have a Depends on the data package. Since some of our packaging
tools apparently don't always cope well with circular dependencies, and
since the data package doesn't really serve any function on its own (so
people won't install it directly), the data package need not have a
Depends on the library.
If the library does not *require* the data to do its job for programs
that link to it, and some subset of cases can work without the data
package installed, then the library could have a Recommends on the data
package instead. If so, that means many people (using the default
settings of the package management tools) will still get the data
package installed by default, and some people (myself included) will end
up choosing whether to install it or not. For that matter, packages
depending on the library might potentially need to make that decision as
well, based on what subset of the library's functionality they use. It
would help greatly if the library package documented under what
circumstances the library needs the data package, to help people decide
if they fit in the subset of cases where the library will function
without it.
The package description seems like the right place to put such
information, since users will see it in a package manager when making
installation decisions about the package. From Debian Policy: "The
description should describe the package (the program) to a user (system
administrator) who has never met it before so that they have enough
information to decide whether they want to install it." It seems fairly
natural to extend that to "whether they want to install it and its
dependencies/recommendations/suggests". Many packages already do this,
noting in their description things like "install $FOO if you want
$THIS_PACKAGE to $FOOFUNC". devscripts represents an extreme example,
noting the specific packages needed by every script it installs, but
most packages don't need to go that far. For a simpler example, check
out autoconf, which Suggests autoconf-archive and gives a reason in its
description.
Before apt started installing Recommends by default, Recommends just
represented a stronger form of Suggests, and both only served as a vague
hint in a package manager that "you might (Suggests) or probably will
(Recommends) want this other package too". Apt now distinguishes
Recommends and Suggests by installing Recommends by default. However,
they still represent varying degrees of hints, and packages should still
function if people install only their Depends.
Given that Recommends have become significantly more prevalent since
this change to apt, I do think it would make sense to write down the
moderately common practice of documenting the reasons why users might or
might not want to install the Recommends/Suggests. I don't think this
should go so far as a "must" in Policy, and in general I'd consider this
either a wishlist or at most a normal bug, depending on the
circumstances. I think "should" seems about right.
- Josh Triplett
Reply to: