[packagekit] Removing packages when updating: a possible solution

[Mounir Lamouri]

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