[packagekit] Resolve function specification

[Mounir Lamouri]

On Mon, Jun 29, 2009 at 5:28 PM, Richard Hughes<hughsient at gmail.com> wrote:
> 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

For me, a package can't be installed and available at the same time. I
mean, package with the same version and the same repository can't be
installed and available at the same time.

So, for me, we have:
installed:
kernel 001 main-repo
kernel 002 main-repo

and in main-repo:
kernel 001
kernel 002
kernel 003

Resolve should returns:
installed kernel 001 main-repo
installed kernel 002 main-repo
available kernel 003 main-repo

if we also have in opt-repo:
kernel 002

Resolve should returns:
installed kernel 001 main-repo
installed kernel 002 main-repo
available kernel 003 main-repo
available kernel 002 opt-repo

I think a package can't have two states (available + installed) is a
valid rule, right ?

> 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.

Oh, here comes a specification for newest.
It really needs one because after testing with fedora, i was thinking
newest = newest package + installed packages (ie. if installed package
is the newest, newest = one package and if installed package is not,
newest = installed + real newest)
So, real specification = newest installed + newest not installed ?

> 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.

That's why I think a package can't be installed and available at the same time.
Even if there is still an issue with repository providing the same
version package than the one installed...

> 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.

I think performance issues are package manager dependants. For
example, portage is keeping a list of installed packages and a list of
available packages (some available can be installed and some installed
can be not available) and I'm already filtering these lists to prevent
double entries.
I don't think this is killing performance.

>> 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.

Indeed, it looks nice but because of some portage-related reasons, It
was easier to go with my own filtering mechanism. I will see someday
if I can merge it with PackagekitFilter propely.

> 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 agree with you, it's better to comes with a skeleton API and see how
it has to evolve. I will not blame you for that, don't worry ;)


Mounir