On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl <mc...@redhat.com> wrote:
> 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 > > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel The hard part is to define what the package tools should do in the different cases A depsolver need to work with real requirements, so it need to be defined in what cases that a soft requirement will become a real requirements to do the right thing And 2 kind of soft deps don't make it more simple. There is lot of actions you can do in a yum transaction : install,update,remove,downgrade,obsolete,reinstall and you can mix them in a single transaction so it gets very complex. Another issue is that Suggests/Recommends is a parent -> child relations When having a package there supports some kind of plugin infrastructure, you have to add recommends for all plugin packages, so each time a new plugin package is added you have to change and rebuild the main package to have a relationship, In that case it would be smarter to have a child -> parent relationship, but that would be very hard to work with if stored in the child spec only, you need some kind of central metadata to handle that. Tim
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel