Re: the Recommends control field (was: dselect survey)
* 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.
With many need one dependency like libraries there is
obviously the program depending the library. (One does
not want to have a virtual package per library, nor
is it feasible to list all packages of programs making
this library useful. And users should not be forced
to make pseudo-packages if they have only some 3rd
party programm linking against the library.)
With data-files I think some possible explanation is
looking down at the mere technical level: Normal data
"works"[1] quite well in the sense it is data and lying
around and nothing to be done with this files causes
any error message more when the non-data package is
not installed. The program on the other hand is intended
to do something and cannot do that without the data.
Thus a dependency from the program to the data is
normaly seen but not the other way around.
Hochachtungsvoll,
Bernhard R. Link
[1]: Of course this is a gross simplification. Be it that
one cannot really distinguish "non-program data" from "programs"
and all the other reasons beside...
Reply to: