tim.lauridsen@xxxxxxxxx wrote:
> 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
See my proposal.
> And 2 kind of soft deps don't make it more simple.
See my reply to James Antill for why 2.
> 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,
That can be discussed as a separate proposal later. Having reverse
dependencies is not a requirement for having regular soft dependencies.
> 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.
We already have such metadata: the repodata! Createrepo can extract that
information from the child RPM and index it by the parent RPM name.
But again, we should get forward soft dependencies working first before we
even start discussing reverse ones. It is obvious that the reverse case is
more complicated, and there is no practical need for blocking the forward
case on it.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
