[packagekit] Removing packages when updating: a possible solution

Mounir Lamouri mounir.lamouri at gmail.com
Tue Jul 21 06:03:18 PDT 2009


On Tue, Jul 21, 2009 at 12:09 AM, Daniel
Nicoletti<dantti85-pk at yahoo.com.br> wrote:
> portage.py
>  - nothing is needed since get depends and requires don't
>   use the filter to filter the packages, there is a TODO there
>   though.

It has been done for both in the last few days.

And about the general idea or I don't get it or I don't like it.
If I get it correctly, you want to use the case recursive=True is used
only to install/remove so we don't need filter as it's supposed to be
always installed/~installed.
I don't like it because you are considering as major client of the API
are using the API in some way is a good reason to consider this way as
the default (and regular) one. You are adding confusion because
recursive=True now means installing/removing. You are also killing
filters usage.

If I get it, the main issue is getting a solution without breaking the
API so we have to found a smooth solution but I've the feeling the
solution you've proposed will also breaks the API but in a more
vicious way.

The issue here is when we emit a package we must set it as available
or installed and when we are emiting dependencies they can be both or
even removing candidates.
Why not using INFO_REMOVING for packages ? It will be used in this
case, when we need to remove a package. It's probably a bit weird
because a package with INFO_REMOVING could also have INFO_INSTALLED
but it seems the clearer way to me to solve this issue.
We could even hope it will not break backward compatibility too much
as maybe clients are setting a value (install/available) as default
and other one otherwise. Even maybe, the package will be ignored (i
honestly don't know how clients are using the api so it's pure
speculation)

Thanks,
Mounir



More information about the PackageKit mailing list