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

[tim.lauridsen at gmail.com]

On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl <mcepl at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/devel/attachments/20110427/c0aa6802/attachment.html