[packagekit] Resolve function specification
dantti85-pk at yahoo.com.br
Mon Jun 29 06:20:25 PDT 2009
>There's one thing I'm not sure about resolve, is whether to return the
>original package. e.g.
>if I have installed dave-002, and there is dave-003 in one repo, and
>dave-002 in another, and I do Resolve(dave, FILTER_NONE) should I get:
>I think the second makes most sense. Might be good to put an example
>in the docs.
Well, now i'm confused.
if resolve is used mostly to install things from pkcon
getting 2 packages might seem a bit weird.
pkcon install dave
imo will "confuse" pkcon or some tool that for some reason use that.
but the SECOND makes most sense to me too.
----- Mensagem original ----
De: Richard Hughes <hughsient at gmail.com>
Para: Mounir Lamouri <mounir.lamouri at gmail.com>
Cc: PackageKit users and developers list <packagekit at lists.freedesktop.org>
Enviadas: Segunda-feira, 29 de Junho de 2009 6:43:36
Assunto: Re: [packagekit] Resolve function specification
On Sun, Jun 28, 2009 at 11:04 PM, Mounir
Lamouri<mounir.lamouri at gmail.com> wrote:
> Still me with specifications. Sorry for bothering and spamming everybody but I
> think it's needed to make things clearer.
No, it's great you're doing things properly, please don't apologise.
> First of all, yum backend is considering the input as a list, not a single
> package id.
I don't think there are any users of Resolve(list) -- I think they all
only pass one thing. I think the idea for multiple terms was to do an
OR search, although in hindsight, there should be a string passed, not
a string list.
> Next, yum backend has a special behaviour. It looks like "newest" is always enabled.
That looks like a leftover part of DNA from the start of the project
(before we had filters). I'm sure we want to compare the same EVR (see
below) but certainly not the pkg.EVR < instpo.EVR part. I'll remove
that bit now. It also looks like yum's resolve doesn't do any
filtering apart from installed. I'll fix that too.
> Finally, this function is even more difficult to manage because specification
> doesn't tell how it's used. Everybody will understand Search* functions are for
> users and most functions use cases are clear. This one is clearly internal but
> how exactly. It will help for backend choices and probably will help to
> understand yum backend choices.
Right, I see from a 40,000ft view of how the API operates:
SearchName(power) matches gnome-power-manager and powerman
SearchDetails(power) matches stuff with power in the description or
summary, or licence, etc
Resolve(power) only matches packages exactly matching, so a package
And then we specify filters such as newest, ~installed and that sort
of thing to narrow down search results.
From an implementation point of view, I don't think Resolve is any
different from SearchFoo, without the wildcarding.
There's one thing I'm not sure about resolve, is whether to return the
original package. e.g.
if I have installed dave-002, and there is dave-003 in one repo, and
dave-002 in another, and I do Resolve(dave, FILTER_NONE) should I get:
I think the second makes most sense. Might be good to put an example
in the docs.
PackageKit mailing list
PackageKit at lists.freedesktop.org
Veja quais são os assuntos do momento no Yahoo! +Buscados
More information about the PackageKit