On Thu, Mar 27, Josef Reidinger wrote:
Hi, I'm sending my proposal for locks API in the attachment. See FATE #120118 and [1] (locks).
The attachment contains io api for locks file and locks-to-pool bridge. Also some functions telling which Resolvables a lock or several locks cover.
question about C++ (function addLocks). I need distinguish between container that contains resolvables and locks. Is this possible in C++? (like Collection<Lock> and Collection<Resolvable> in java?)
some ideas how to solve the issue with support of regexes or wildcards in the locks file:
Instead of class Lock: Maybe we should think about save/restore queries. - A (locks) file contains a set of queries. We restore these queries from a file. - Executing the set of queries then leads to a set of solvables. - We can execute any algorithm on these solvables. If the queries came from zypp.locks, we can e.g. lock these solvables. --- 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. --- 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. ---
Other issues: - how to clean up or maintain the locks file, it will probably be a mess after some time
We provide some interface to maintain the lock file. - list all rules - list items covered by a rule - maybe track the last time the rule matched somthing: yast2-packagemanager: This rule did not match any item for more than one year. Do you want to keep int anyway? yes no
- 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. If we'd have PoolQuery that can be serialised to, and reparsed from, a string, we have a versatile object. We can provide some query editor that displays a set of queries. Supports adding/removing/editing the queries. This editor can be used to maintain the queries retrieved from zypp/locks. The result is written line by line into /etc/zypp/locks. This editor can also be used to maintain named queries (if) the UI allows the user to define (them). Those named queries could be saved in some different (ini)-file. Those queries could be shared with zypper zypper query 'installed_last_week' ... A lock is a query, and it's result serves a special purpose. A lock is not a special query. ----- c++ related: /** * removes all locks in container from file */ template <class Container> void removeLocks( Container &container ) const; ( If Container itself is not modified pass a 'const Container &'. ) - Your interface should (always) be iterator based (maybe a container interface for convenience): template <class Iterator> void removeLocks( Iterator begin, Iterator end ) const; template <class Container> void removeLocks( Container & container ) const { removeLocks( container.begin(), container.end() ) } Look ar classes like the sat::Pool or ResPool, they have a couple of iterators: sat::Pool::reposBegin() sat::Pool::reposEnd() sat::Pool::solvablesBegin() sat::Pool::solvablesEnd() and a plain array like int val[] = { 1,2,3,4 }; has no begin()/end() methods but Iterator void print( int ); std::for_each( val, val+(sizeof(val)/sizeof(int)), print ); Iterator is the most versatile item here. -- 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