Mailinglist Archive: zypp-devel (57 mails)

[Michael Andres <ma@xxxxxxx>]

On Sun, Jan 27, Duncan Mac-Vicar P. wrote:

> > Enumerate all packages that belong to an RPM group (not just for leaf RPM 
> groups, also those that belong to a higher level like "Productivity") 
 
> I think the best way to solve this problems is to introduce categories for 
> all 
> resolvabes (tags), in the case of packages it can be implemented using rpm 
> groups, and implement iterators to match full tag, part of it, a collection 
> of them, etc.

We have filter iterators. We basically need to collect the common filter 
functions inside zypp so they are available to each application. 

More important is a nice and easy syntax to combine simple queries to 
create more complex one. 

And a fexible way to process the result as either a collection of 
individual PoolItems or sort of Selectables.



> > Changing the status of a pattern, patch, or language typically affects the 
> status of other resolvables, most notably the packages that belong to this 
> pattern, patch, or language. Those changes should be propagated immediately 
> to those packages so the user can instantly see the effect. 
> > In the past there were calls to just propagate those changes, which worked 
> > in 
> most cases, but not in certain pathological ones. But those calls were quick, 
> so for the user there was an instant response.
> > Recent changes rely on a full solver run to propagate the changes, which 
> gives the correct result in all cases, but which on the other hand is much 
> slower. As some users disable the automatic dependency check because of this, 
> some of them get confused because no change is propagated. There have been 
> bug reports with lively discussions about that. 
>
> I read this as, we need to do a solver run without doing a solver run?
>
> This is a technical limitation, which could be solved of we could for example 
> cheap-ly clone a pool , do something and see the changes, without making the 

You don't need to clone for this. 

The solver does not change the pool status. The pool status are translated 
into a jobdescription. The solver processes this description and returns 
a result list. This result list can be written back to the pool or used to 
just create a 'diff'.

But a solver run does not help you to determine something that can be 
displayed as 'pattern content'. IMO the current approach is ok. 

It's probably more important to collect and provide the appropriate 
interfaces in zypp. 



> main one dirty. I have no idea yet if that undocumented dirpool has something 
> to do with that ;-)

No, dirpool is the internal representation of pathnames as (dirname, 
basename) tuples  (didn't you read the source?).



> > Update Problems Filter View
> > This filter view enumerates those packages that for one reason or the other 
> > could not automatically be updated during a system update. Adding packages 
> > to this list is done by the system update application layer. 
>
> And what is the criteria for searching those?

We'll have to see if this still applies. 

The 'old' update algorithm went through all installed packages, looking 
for an appropriate replacement. So we were able to tell why some package 
was selected, and if there was no replacement for a specific package.

This is most probably not true if the solver updates the system. We have 
to see how to interpret and visualize the result we get back from the 
solver.


 
> >    *  Create pool iterator (based on the above query as a parameter)
>  >  Pool pool = new Pool (q); 
>
> So this is like a pool proxy based on a query? Why not the iterator taking 
> the 
> query as a parameter (Michael could comment more?)

Or the Query will provide an iterator to the result. But not create 
some result container. It's easy for the application to do this, if 
desired.

        set<PoolItem> result( query.begin(), query.end() );



-- 

cu,
    Michael Andres

+------------------------------------------------------------------+
Key fingerprint = 2DFA 5D73 18B1 E7EF A862  27AC 3FB8 9E3A 27C6 B0E4
+------------------------------------------------------------------+
Michael Andres             YaST Development            ma@xxxxxxxxxx
SUSE LINUX Products GmbH, GF:  Markus Rex,  HRB 16746 (AG Nuernberg)
Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0
+------------------------------------------------------------------+

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