[packagekit] WhatProvides

[Richard Hughes]

On Mon, 2008-03-17 at 14:40 -0400, Robin Norwood wrote:
> > On Mon, 2008-03-17 at 18:52 +0100, Klaus Kaempf wrote:
> > > Whats the purpose of having an enum if its semantics could be
> > > encoded in 'data' ?
> > 
> > Valid point, but I felt it was better to split out the type in a
> > separate data flag to avoid parsing in the daemon. Plus it makes
> > filtering easier, but I don't think that would be a common case.
> > 
> > Ohh, and we probably need a filter parameter to WhatProvides too, as
> > we really don't want to filter this on the frontend.
> 
> Is there any way that these codec-based "Provides" are different
> from regular provides, aside from the fact that you're targeting the
> codec and module problems now?

Well yes. We might be looking in different metadata or databases. Just
because yum treats a package dep the same as a codec provide doesn't
mean it's a good thing to do in a general purpose API.

For instance, GetDepends returns a list of packages, rather than any
sort of other meta-package or modalias things. As soon as we start
letting PackageKit understand the specific dep-solver then we are going
waaay to deep for an abstraction.

> All we're really saying is 'what
> packages resolve this dependency?' I don't think any of the backends
> care what 'type' of dep it is.  Yum at least will treat them all the
> same, unless I'm missing something.  I think we'll just end up with a
> bunch of duplicate code in the various backends that do the same string
> matching each time.

Sure. For the yum backend it might very well be the same code, but for
the others it might have to do very different code paths. Other backends
like opkg might not care about modaliases and codecs and so using them
in the existing API would fail.

Backends that lack metadata might just have a simple lookup table for
the different codecs - I think it's important we keep the flexibility.

> Hrm.  Again, if the actual strings for deps are going to be different
> between backends, then we might need this.  Otherwise, the yum backend
> at least won't care, as far as I know.

Sure. I guess the yum backend is an easy one to convert :-)

Richard.