[packagekit] Resolve function specification

[Richard Hughes]

On Mon, Jun 29, 2009 at 3:39 PM, Mounir Lamouri<mounir.lamouri at gmail.com> wrote:
> I'm a bit lost.

That's because we're designing (re-designing) the API to be better all
the time. Don't worry, I keep changing my mind too :-)

> Does this mean we are going to show same version
> packages except when newest enabled ?

Ignore newest for a moment. Newest should really be orthogonal to the
"show available package for installed packages" problem. If I'm
searching with ~installed then I'm probably only searching the remote
sources, and not even opening the local package store.

For instance:

installed:
kernel 001
kernel 002

in repos:
kernel 001
kernel 002
kernel 003

Resolve(kernel,none)
installed kernel 001
installed kernel 002
available kernel 001
available kernel 002
available kernel 003

Resolve(kernel,installed)
installed kernel 001
installed kernel 002

Resolve(kernel,~installed)
available kernel 001
available kernel 002
available kernel 003

Resolve(kernel,installed;newest)
installed kernel 002

Resolve(kernel,~installed;newest)
available kernel 003

Resolve(kernel,newest)
installed kernel 002  <--------- two packages, newest in each
available kernel 003 <---/

So, newest operates on each (installed,available) list independently.
This should clear up any confusion with what the 40,000ft view should
look like. But then there is the searching problem.

Let me illustrate with an example.

$pkcon install dave

pkcon does a Resolve(dave, newest;~installed), and then sends the
result to InstallPackages.

But, without duplicate-version-comparing, if I have dave 001
installed, and 001 is available in the repos, I'll get "available
dave-001" as a response, and then I'll try to install the package that
I've already got installed.

Now, this could be fixed by doing an extra Resolve(dave,installed)
before the remote search, just to check if the package is installed or
not, and probably is a good idea, except for packages like kernel
which can have multiple versions installed in parallel.

The problem is that we don't really don't want to do this for search results.

If I have dave 001 installed, and I do SearchName(dave,none) I'm
expecting to show to the user one package that is installed, not one
package that is installed, and (to the naive user) the same package
that can be clicked on and installed. It's just confusing to show the
user an option to install a package that is already installed.

So in this case, maybe we need a new filter called
"skip-installed-version" (better name welcomed) that effectively does
this:

#get search results like normal
#for each package in list
#  if package_is_available
#    if same package is installed of this name and version
#      remove from list

So we can do the pkcon install resolve like this
Resolve(installed;newest;skip-installed-version), and do
gpk-application SearchNames with "skip-installed-version" selected in
the GUI by default.

For instance:

installed:
kernel 001
kernel 002

in repos:
kernel 001
kernel 002
kernel 003

Resolve(kernel,skip-installed-version)
installed kernel 001
installed kernel 002
available kernel 003

Resolve(kernel,~installed;skip-installed-version)
available kernel 003

Now, maybe you're thinking we could just use skip-installed-version
mode by default, and I might agree with you. The only problem is
matching every package against the system database might be a big
performance hit, in cases like GetPackages(). It depends how much you
value performance over API ease of use.

> By the way, for some reasons, I'm not using PackageKitFilter so it
> should better documented even if coded here.

Ohh sure, PackageKitFilter is just a helper. I think it's quite a nice
helper and it's good to share code, but you're free to do as you wish.
The spec has to be the 100% definite source of policy.

Ohh, and in case you're wondering "why didn't Richard lock down the
API and define the methods properly..." I wanted the API to evolve and
be changed with different backends. Trying to define the problem
before you're trying to solve the problem is very difficult. As you'll
have seen with the recent only_trusted thing, I'm not afraid of
changing API if a new problem needs to be solved.

I think we're getting to the point where the specification is getting
more-tightly defined, and PackageKit as an architecture gets more
useful.

Richard.