Re: the Recommends control field (was: dselect survey)
On Thu, 25 Nov 2004, Steve Greenland wrote:
> On 25-Nov-04, 07:37 (CST), Henrique de Moraes Holschuh <hmh@debian.org> wrote:
> > On Thu, 25 Nov 2004, Thaddeus H. Black wrote:
> > > (a) The social interpretation: a Recommended
> > > package is one the maintainer recommends
> > > to his users, in the usual English-
> > > language sense of the word "recommends".
> >
> > Hmm... that is certainly NOT how it should be used. We really should have
> > called "recommends" "weak-depends" or something.
>
> Hmm... I'd have said that a) was the preferred interpetation; if a
> package foo is effectively useless with a Recommended item bar, then bar
> should, in fact, be a Depends, even if foo will start without bar. I
What about "it works but feature foo (which is not a core functionality)
won't work without package bar installed. If you call feature foo, the
program complains (and maybe aborts in a most ungraceful way)"
(this is a weak depends).
And "will not work without package bar unless you change the configuration
to use something else" (example: timidity and freepats). This is also a weak
dependency.
And "used to be a depends, and if we make it a suggests which is the correct
thing to do, it will cause trouble during an upgrade, so we do a two-stage
migration from depends to recommends to suggests", e.g. dselect. This is
ALSO a weak dependency.
My guess is that we can blame all of this on Culus. apt-get follows the
social interpretation (due to Culus "don't use apt-get, it is not for the
end user" instance, I suppose). dselect uses the technical interpretation.
And dselect came first, so we know what the Recommends header was made for.
OTOH, if people are using it so much as a strong suggests (social sense),
maybe we need that functionality too.
If the idea of a social interpretation of recommends is something useful (I
doubt very much so, IMHO suggests is enough, and we don't have a good reason
to think we know THAT MUCH better than the user and thus need two levels of
suggests) then we certainly could have *two* not-really-a-depends fields.
One for the social "strong suggestion" and another for the technical "weak
dependency". "Recommends" could be either (in fact, I'd use it for the
social one, and use weak-depends for the technical one, since that's
probably less error prone).
> So it is likely that Policy does, in fact, need clarification, but I'd
> expect long discussion about what the clarification should be.
Unless we split the functionality such that we have both, I think you're
correct. I know for sure we can't do away with the technical recommends.
I'd rather we separate the social one (or kill it altogether) so that we can
finally fix apt-get and stop the annoying bug reports of people who do not
even KNOW they are not supposed to ignore a technical recommends unless they
Really Know Better.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: