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
suggestion, why is used repo_search in implementation? Is not possible use search through pool and use its indexes which can have better performance? (when ui generate 300 per name locks and then search all repos (when you don't set repo restrict) looks quite slow for me)
Inside QueryPool we can do whatever we like to improve speed.
some string representation which I think can be useful
LDIF format - atribute name comma value, records separated by blank line (ui often generate only one line name at the easiest case) example: name: foo version: ==4.2.3 kind: patch ---end example
advantage - easy to change attribute without backward compatibility break, good readable also when you see first time this string disadvantage - lot of data, file can be large, cannot use in log (in my way)
xml - I think everybody know it. Not so easy to parse. We're no longer in the 90s, we don't have to use XML for everything.
--- Need to recheck locks when new items are added to the pool: We can either - make the restored lock-queries available to the pool (or - we need some signal if the pools content changes) --- We can make a 'waslocked'-bit availabe in the ResStatus, to remember all solvables covered by a lock-query. Later in commit we can check whether there are solvables: - locked but not 'waslocked' (lock added by UI) - 'waslocked but unlocked (lock removed by UI) Locks added by the UI are treated as name-locks ("foo", not "foo==1.2.3"). These could be added to <targetroot>/...zypp.locks. Locks removed added by the UI are simply ignored. But we could remove any exising name lock, then the package will in fact be permanently unlocked, if no complex rule matches it. (no regex no cry). If I want to lock 'kde*' but not 'kden', I have to refine my regex.
I don't understand this. So when ui remove lock added from locks file, remove it at end also from locks file(and generate for other locked package from regex ui simple lock) or don't remove it and user must refine his regex?
The UI(single package selection) should only add/remove name-locks (name:foo, no other condition) when toggeling the status. If such a lock is to be 'removed', we'd remove a lock (name:foo) if it exists. Unless the package is also hit by a more complex lock, it will appear unlocked next time. If there is a 'complex' query that hit the package (name:f*o), the package will continue to be locked until the user changes the 'complex' query.
- the locks file format will be extended to include resolvable kind. The question is whether we want to support also something else (architecture, vendor, ...) Whatever a PoolQuery is able to understand ;) - the API supports locks file <-> pool manipulation as well as direct to/from locks manipulation, is it OK? I somewhat dislike the approach, that each application is responsible for reading and (re)applying the locks to the pool. If we want to support a global lock file /etc/zypp/locks, there could be some option turning zypp.lock support on/off. But if it is on, the pool which is responsible for building the transaction should be responsible for reading and (re)applying the locks.
so locks communicate only with pool except for some question on locks and locks maintain?
Locks could be something like a Container<PoolQuery> that also offers methods to read from and write to a file. (I would not call this class Locks) PoolQueries locks( "/etc/zypp/lock" ); // do something with locks locks.write( "/etc/zypp/lock" );
Iterator is the most versatile item here.
InputIterator have problem, that don't ensure validity after increment, so you can only onetime iterate over input iterators. So when use container you have more implementation freedom. It's trade off versatile for possible more time iterate (this can sometime help).
(nit-picky ) If you use 'template <class Container>' you also can't be shure it's iterator has the properies you expect. If you depend on certain properies the compiler can't detect, then you should implement mpl-tests to trigger compile time instead of runtime errors. And if you implement mpl-tests, you could as well do it in the Iterator based interase. You don't assume your method will be called with std::vetor and std::list, ... only, do you? -- 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