On Tue, Apr 26, 2011 at 8:55 PM, Matej Cepl <mcepl@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
