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