[packagekit] Removing packages when updating: a possible solution

[Mounir Lamouri]

And, btw, this solution will let the client to look for removing
rights and break if not available.

On Tue, Jul 21, 2009 at 3:03 PM, Mounir Lamouri<mounir.lamouri at gmail.com> wrote:
> 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
>