[packagekit] API proposal: Extended method to fetch dependency information

[Matthias Klumpp]

Hi!

2013/6/29 Richard Hughes <hughsient at gmail.com>:
> On 29 June 2013 00:12, Matthias Klumpp <matthias at tenstral.net> wrote:
>> DEPENDENCY_TYPE_DEPENDS - The hard dependencies of a package
>
> Sounds fine.
>
>> DEPENDENCY_TYPE_SUGGESTS - Packages which this package suggests to be installed
>
> Sounds okay.
>
>> DEPENDENCY_TYPE_REVERSE_DEPENDS - The reverse dependencies on this
>> package (= other packages depending on this package)
>
> I don't think REVERSE_DEPENDS is very clear what this means. Perhaps
> DEPENDENCY_TYPE_REQUIRES?
IMHO REVERSE_DEPENDS is much more clear, because "Requires" suggests a
requirement of *the current package*, because any dependency is by
definition a package requirement. Choosing something like REQUIRED_BY
would make it much more clear that the call will return packages
requiring the first package to be present.

>> For Debian distros, a _RECOMMENDS type (stronger dependency than
>> Suggests, but not as strong as Depends) would also be nice, but not
>> necessary.
>
> I think if you include this, you need to define what each term means,
> with examples.
The definitions of each term can be found at
http://www.debian.org/doc/debian-policy/ch-relationships.html ,
section 7.2.
It says "The Recommends field should list packages that would be found
together with this one in all but unusual installations.". Therefore,
I am not 100% sure if we want to expose this flag on the PK interface
- it is needed for completeness in a Debian world, but usually treated
just like a usual "strong" dependency. Regardless of that, it allows
people to further customize their set of packages.
(To give an example, the libpackagekit-glib2 library on Debian has a
Recommends on the package containing the PK daemon, to avoid a
circular dependency)
Does Fedora have something similar? If yes, I would vote for adding
the property, if not, I'd want to check which other PMs also provide
similar features.

>> Adding this function would deprecate the current GetDepends() and
>> GetRequires() calls and unify them in one new call.
>
> I think that's fine, on the premise you call the backend
> get_requires() and get_depends() methods as a compat fallback, or
> maybe just convert all the backends to the new scheme. The only
> drawback I can see with using a depends_kind is that a backend can't
> say "I support DEPENDENCY_TYPE_ENHANCES but not _RECOMMENDS", and that
> was the original reason of having two different methods.
Okay, that's true... Can we maybe define the case where NULL is
reported as "The backend does not support this method", and the case
where an empty array is returned as "There are no dependencies
matching the filter"? Maybe there is even a cleaner way to do this...
In theory, we could maybe also use the standard PK package filter for
that, where backends declare which features they support.

Regarding _ENHANCES: Enhances is just a reversed Suggests, maybe we
can include it in the Suggests filter, instead of creating a new one?

Cheers,
    Matthias

P.S: I am writing exams at time, so implementation of this is delayed,
unless somebody else does it ;-)