[packagekit] Removing packages when updating: a possible solution

[Daniel Nicoletti]

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

Of course Removing could be used but it's much uglier imo, since removing
is only used when we have the transaction running to inform the current
state. "Package foo is removing".
I'm no english speaker but removing isn't right in my point of view.

Also, recursive = true, is ONLY used before install/remove,
no other place of both gpk or kpk use it.
Yes, I'm "killing" the filters when recursive is set
actually they will still work but "INSTALLED" will be
added if recursive ius true...
There is no use case where recursive is needed with filters.
Why someone would want the newest recursive deps? or
the gui recursive deps?
In the API docs I'll try to make it as clear as possible if
a filter is set, Maybe we could add an
ERROR_FILTER_SET_WITH_RECURSIVE.

>You are adding confusion because
> recursive=True now means installing/removing.

But it means, no other piece of code uses that,
and I don't see any use cases where someone will want it.

What do you think now?

Thanks,
Daniel.


----- Mensagem original ----
> De: Mounir Lamouri <mounir.lamouri at gmail.com>
> Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
> Enviadas: Terça-feira, 21 de Julho de 2009 10:03:18
> Assunto: Re: [packagekit] Removing packages when updating: a possible solution
> 
> On Tue, Jul 21, 2009 at 12:09 AM, Daniel
> Nicolettiwrote:
> > 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
> _______________________________________________
> PackageKit mailing list
> PackageKit at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/packagekit



      ____________________________________________________________________________________
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com