Re: the Recommends control field (was: dselect survey)
* Steve Langasek <vorlon@debian.org> [041126 03:57]:
> 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.
While I'm absolutely agree with this, I believe the common sense you
quote is mostly from experience and not a priori.
Looking with some "uncommon sense" not yet connected to the common
soul: Let "foo" and "foo-data" be called "foo-player" and "foo" instead,
why not call them so and reverse the dependency.
Why needing some complex mechanism for looking which libraries are no
longer needed, when package tools would have to deinstall them
automatically when no package making them useful is anymore present.
Of course this are stupid ideas, it may be even evident that they are
stupid, but is evident why exactly they are stupid?
> [...]
> 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.
While it is correct it its own right (which I missed to mention), as it
results in a consistent notation doing the right thing, there could be
other correct solutions. I tried to give some reasons why this is also
sensible locally.
> 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.
This is also a argumentation looking back. While this again states how
sensible the current behaviour is, why do you state such a technical
position, when it is enough to say it is correct in its own right? ;-)
Hochachtungsvoll,
Bernhard R. Link
Reply to: