[packagekit] Fwd: Resolve function specification

[Mounir Lamouri]

Forwarding Richard answer.


---------- Forwarded message ----------
From: Richard Hughes <hughsient at gmail.com>
Date: Mon, Jun 29, 2009 at 4:14 PM
Subject: Re: Resolve function specification
To: Mounir Lamouri <mounir.lamouri at gmail.com>


On Mon, Jun 29, 2009 at 3:02 PM, Mounir Lamouri<mounir.lamouri at gmail.com> wrote:
> So, we can consider the specification is correct and yum backend has
> to be fixed ?

Yes. I've fixed up the worst of the yum backend already.

> (ie. only one name should be passed to the function) or we move to a
> string with multiple keys separated with spaces and result is with OR
> operator ? (ie. Resolve("foo bar") = Resolve("foo") + Resolve("bar"))

Given that resolve supports list input, I think disallowing spaces in
each search term is the way to go. Given that I can do
Resolve(["gnome-powermanager","hal"] I don't thinks we need to support
Resolve(["gnome-power-manager hal", "gnome-session"])

> Why the second makes most-sense ?

I guess my logic is that PackageKit doesn't support re-install, but I
guess that's an assumption that probably shouldn't be valid. My main
concern is searching. If I'm searching to install gimp-libs (and it's
already installed), and I type in "gimp libs" then I want to show the
user one package that is installed, and not one package that is
installed, and an identical one that is available. As the two packages
have equal versions, the newest filter isn't going to save us in this
case, and the user isn't going to know if it's supported or not. I
don't really want to be doing any filtering on the client at all if
possible.

> If we have a Resolve special behaviour it's going to be hard to
> understand and as Resolve is atm used with ~installed;newest, this
> special behaviour is not needed.

I think SearchName and SearchDetails need to have the
duplicate-same-version-removal logic added to the spec too, although I
don't mind discussing this further.

Richard.