Mailinglist Archive: zypp-devel (227 mails)

[Josef Reidinger <jreidinger@xxxxxxx>]

Michael Andres wrote:
> On Fri, Mar 28, Josef Reidinger wrote:
>
> > Michael Andres wrote:
> > > I'd sugest to imporove PoolQuery, so it is able to be constructed from 
> > > some string representation (e.g. a line in zypp/locks). Nice if each query 
> > > is as well able to save itself in a human readable reparsable string. 
> > > Otherwise things are reimplemented in Lock and still missing in PoolQuery.
> > Yes, good idea. I look at it and query looks good and reusable. Only 
>
> But it is not complete. More a first draft.
>          
> - typedef function<bool( const ResObject::Ptr & )> ProcessResolvable;
>          
>   This in IMO the least usefull item here (ResObject::Ptr). Query should
>   IMO return the matching sat::Solvables. All the other types (ResObject
>   Package, PoolIterm, Selectable) can (or will) be constructed from the
>   sat::Solvable as needed.
Thanks for response.
only one another think which I don't understand:
  I look at code and and look like that way Solvable->PoolItem is 
harded then back way. Because PoolItem store Resolvable and from 
resolvable is easy extract solvable (code looks easy to execute). But 
constructing PoolItem from solvable needs finding throught whole pool 
(which can be optimalize, but I think is much difficult then extract 
solvable from resolvable).
So is not better returns PoolItem instead of solvable? Or I overlook 
something?

thanks,
Pepa
--
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx