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@novell.com 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@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org