Suggests/Recommends proposal [Was: Re: PackageKit in Fedora 15 (beta)]

[Matej Cepl]

Dne 26.4.2011 18:23, Florian Festi napsal(a):
> I think if anybody can come up with a exact description how they should
> look like and how they should work and can create some evidence that
> this is want we need and want implementing them is not the problem[*].
> Until now no one has come up with a proposal and enough confidence.

Well, I would for starters just take 
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps 
as a basis for the further refinement.

== Recommends ==

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together 
with this one in all but unusual installations.

== Suggests ==

This is used to declare that one package may be more useful with one or 
more others. Using this field tells the packaging system and the user 
that the listed packages are related to this one and can perhaps enhance 
its usefulness, but that installing this one without them is perfectly 
reasonable.

-----------------------------------------------------

As an examples of Recommends I heard crond (or procmail) and 
/usr/sbin/sendmail ... strictly speaking crond (and procmail) work 
without sendmail, but almost never seen the former without the latter, 
and usually if you want that it is some very special case, where 
administrator knows what he is doing.

On the other hand the case in the hand ... gnome-settings-daemon and 
packagekit (or phonon-gstreamer-backend and its packagekit plugin) would 
be Suggests — there are many real world scenarios where one could live 
without PackageKit, but there is no discussion that PK plugin (when it 
works, that is) could be very useful addition for totem or phonon.

> As soon as one looks at the details it becomes less obvious what "we
> really want". Even whether the Suggests/Recommends should live in the
> packages or in comps or else where or both or both or in all three is
> still under debate.

IMHO, Suggests/Recommends should live in the spec file and be maintained 
by the package maintainers.

> Do we need reverse relations? Do we really want to
> have exactly two levels of strength? Do we need "conditionals" (install
> an package only if two or more other packages are installed) as we had
> (have) in comps? Or should be trash the whole concept of comps and comps
> groups and start all over? When and how should they be evaluated? Do we
> need to save the users decision not to want the suggested package? What
> happens if the Suggests changes during an update?

We can work on these more elaborate ideas later, but I think that the 
plain introduction of the Suggests/Recommends as outlined above 
(roughly, I guess there would be a lot of discussion about that even) 
would be nice starter for F16 (with a lot of bugs to discuss what level 
of dependency is required for each particular case). We can deal with 
the esoteric cases you suggest later.

And specifically about comps ... no, I would leave them in cases where 
they are useful (i.e., roughly anywhere they don't do work of S/R 
dependencies). They are useful for suggesting grouping of packages and 
organization of installation models (i.e., definition of what's Desktop, 
what's KDE, etc.). And even then I don't think there is a need for any 
rush to replace comps any time soon ... the biggest value of 
Suggests/Recommends IMHO is the possibility to break unnecessary 
Requires which make these nonsensical situations (i.e., you need 
PackageKit in order to have gdm).

> So I am not too optimistic that we'll have Suggests or
> Recommends any time soon.

As I said above I have been saying this for almost five years already. 
It took Cato the Elder fifty years, so I think I have still some way to 
go :)

> [*] Depending on the exact features implementing still can be tricky and
> require a lot of work. I doubt that it will be even remotely close to
> half an hour but nothing that cannot be handled.

Of course, I expect that it was half an hour used in a Pickwickian manner.

Best,

Matěj