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

[Sebastian Heinlein]

Am Mittwoch, den 03.07.2013, 16:10 +0200 schrieb 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.

The passive term REQUIRED_BY would also be clearer to me than REQUIRES.
But perhaps this is only confusing for non native speakers.

> >> For Debian distros, a _RECOMMENDS type (stronger dependency than
> >> Suggests, but not as strong as Depends) would also be nice, but not
> >> necessary.

But why would you need a recommends type in the package installer
application? For the end user the difference between a soft and a hard
dependency should not be a matter.

The suggests type contains software that won't get installed by default,
but could be interesting.

So depending on the config value of APT::Install-Recommends recommends
could be reported as suggests or dependencies. 

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

Good idea.