[packagekit] Removing packages when updating: a possible solution

[Daniel Nicoletti]

Ok, here is the first draft of install_package_simulate.
Can someone take a look to see why pkcon does not call it?
I'm still trying..
When this is ok creating remove_package_simulate and update
will be mostly copy & paste.

* note that i didn't change all backends, i'll do when this
work with dummy.

Thanks,
Daniel



----- Mensagem original ----
> De: Daniel Nicoletti <dantti85-pk at yahoo.com.br>
> Para: PackageKit users and developers list <packagekit at lists.freedesktop.org>
> Enviadas: Terça-feira, 21 de Julho de 2009 11:07:23
> Assunto: Re: [packagekit] Removing packages when updating: a possible solution
> 
> 
> > 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 
> > Para: PackageKit users and developers list 
> > 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
> _______________________________________________
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: simulate
Type: application/octet-stream
Size: 19847 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/packagekit/attachments/20090803/dfe2c3a9/attachment-0004.obj>