On Thu, Nov 25, 2004 at 07:28:01PM +0100, Bernhard R. Link wrote:
> * Thaddeus H. Black <t@b-tk.org> [041125 17:12]:
> > NON-RECOMMENDING PACKAGES
> > ------------------------------------------------
> > Here are some ${X}-data packages which no not
> > seem to Recommend (or Depend on) the
> > corresponding ${X}. Some of these ${X}-data may
> > be useful without the ${X}, but their
> > independent usefulness is not immediately
> > obvious to me.
> I think most dependencies (in the sense including
> recommends) are two-way in some form, but most
> of the time only one of them in represented.
> E.g. Library packages are not very useful without
> either an program linking against that one or
> a development package around.
> Though most of the time one of those "dependencies"
> is more "evident" than the other.
Rather, one of these "dependencies" is useful to the end user, and the other
is not. The whole point of dependencies is to ensure that *when a user
chooses to install* a package (or a bundle of packages, as in the case of
metapackages and tasks), everything needed to use that package/run that
program is installed with it. But users should not select packages named
foo-data and libfoo42 for installation; Common Sense(tm) tells them that
these packages are not directly useful.
If users are not installing such packages directly, that means they'll only
be installed when pulled in automatically by other packages which already
depend on the libs or data in question; therefore, there's no need to
declare a reciprocal dependency (not that this would be meaningful in the
case of a lib package, anyway, or even in the case of many data packages).
You seem to have arrived at the same technical position in the end, but your
arguments leave room for the notion that the current behavior is a
compromise. I disagree with this; I think the current behavior is correct
in its own right.
From a release standpoint, while we don't want -data packages to be released
without the programs that make them useful (in those cases where, for some
reason, the -data comes from a separate source package from the program),
reciprocal dependencies aren't much of an improvement currently, as they
require the release team to intervene to hint such package pairs through
into testing.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature