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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110321224836.GE14195@feather
