On Thursday 27 March 2008 16:17, Stanislav Visnovsky wrote:

...

- the locks file format will be extended to include resolvable kind. The    question is whether we want to support also something else    (architecture, vendor, ...)

repository (stick to repo)

<dreaming>number of installed instances of the package</dreaming> - might be useful to maintain the number of installed kernels.

Hm - is the number really meaningful? I think I'd like to keep the original kernel (the one I got during installation), the last one I consider stable, and maybe the last 2-3 kernels of the day. It would probably be hard to express this in rules. CU -- Stefan Hundhammer Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Dňa Thursday 27 March 2008 16:11:04 Josef Reidinger ste napísal:

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:

- keep support of regexes in the locks file - have function which does something like locks coverage. How would it work? It would get old locks and resolvables which the user wanted to lock (including the changed ones). Then, for each lock it gets all matching available resolvables and checks if the set is a subset of currently locked resolvables. If it is, those resolvables are marked as already locked (written/covered/whatever) and the lock is written back to the locks file unchanged (meaning if it was a regex, it will stay so). Thus the remaining resolvables will be written to the locks file individually (without using any regex).

This may not be trivial.

- drop regex support and write one lock per resolvable

- use two files for user (regex) locks and UI locks (as suggested in [1])

Other issues: - how to clean up or maintain the locks file, it will probably be a mess after some time - the locks file format will be extended to include resolvable kind. The question is whether we want to support also something else (architecture, vendor, ...) - the API supports locks file <-> pool manipulation as well as direct to/from locks manipulation, is it OK?

What should happen with locks during system upgrade? Stano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Hi, On Thu, 27 Mar 2008, Josef Reidinger wrote:

Hi, I see same. Drop support mean that no one can use regex in this file (user cannot add this also), so this is not possible. (no a* in lock file). Your idea have problem when user want unlock abcd package.

Hmm, true. This could be solved by a hierarchy of locks and unlocks, the last one wins. E.g. with lock:a* unlock:ab* lock:abcde all a* would be locked, except the ab* which are not locked, except abcde which is locked again. But this quickly gets out of hand for no big benefit (not many people are writing regex locks). Hmm. Ugly. I kind of liked the possibility of the regex locks, though this was only supported if written by hand, and interacted strangely with locks from the GUI. Does anybody have convincing use-cases for regex locks (i.e. any other than abstract niceness)? Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

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

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 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) some string representation which I think can be useful symbol separated fix collum - like name;Version;Kind advantage - small, easy, good to use with cut disadvantage - not flexible, bad to update, need know what each collum mean 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) LDIF oneliner - all atribute in one line. e.g. name:foo version: ==4.2.3 kind: patch advantage - same as LDIF, maybe worse readable by human, can used in logs, not too much screens when you look at it disadvantage - worse readable xml - I think everybody know it. Not so easy to parse. I think that best is LDIF to output and oneliner LDIF to log (xml is not human readable, I think only crazy people want read more then one screen xml output :)

---

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?

---

...

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

yes, this api cover it...only need decide how many this function is used list all rules - save locks queries or reread it each time? list items covered by a rule - only execute on query, not?

- 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

where store this? how often save it? what to do if someone install one time per year? When user remove repository and for example 30 filter is no not matching...isn't confusing if user after year gets this question after year?

...

- 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?

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 &'. )

yes, I forget it. good mention

- 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.

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). In rest of libzypp code is used iterator, so I use it also. Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Josef Reidinger wrote:

Ok, so I only make seriazeble and deseriazable of PoolQuery (may I use

...

...

and <

When I do this I get idea what about make universal serializeToFile function which take as input iterators to object which have operator<< and also recoveryFromFile. It can be part of base something like this template <class InputIter> void serializeToFile( InputIter begin, InputIter end, const Pathname &file){ ofstream s( file.c_str(),ofstream::trunc | ofstream::out ); s.exceptions( ofstream::bad ); try { copy(begin,end,ostream_iterator(s)); } catch (ofstream::failure f) { ZYPP_THROW(something about file failure); } } template void recoveryFromFile(const Pathname &file,OutputIterator out){ ifstream s( file.c_str(),ifstream::trunc | ifstream::out ); s.exceptions( ifstream::bad ); try { copy(istream_iterator<Data>(s),istream_iterator<Data>(),out); } catch (ifstream::failure f) { ZYPP_THROW(something about file failure); } } also append to file can be usefull. So when pool stores queries which have << and >> operators, they can easy serialize and recovery it. e.g. set<PoolQuery> locks; //load locks insert_iterator ii(locks, locks.end()); recoveryFromFile<PoolQuery>( "/etc/zypp/locks", ii); //save to file serializeToFile(locks.begin(),locks.end(),"/etc/zypp/locks"); and thats all What do you think about this? Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Fri, Mar 28, Josef Reidinger wrote:

Ok, so I only make seriazeble and deseriazable of PoolQuery (may I use >> and <

Yes, that's what I'd sugest. -- 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

On Tue, Apr 01, Josef Reidinger wrote:

...

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).

Yes, but this is subject to change. I'd like the poolItem to store the Solvable, and delay creation of the resobject. But' that's not (so ) urgent.

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).

The method used is called 'ResPool::find', but the pool knows where he created his item. So find is basically range check and array access. return( slv_r.id() < mystore.size() ? mystore[slv_r.id()] : PoolItem() ); The PoolItem ctor from solvable is nothing but a convenience. Only the pool actually constructs them. -- 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

On Tue, Apr 01, Josef Reidinger wrote:

...

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.

Maybe better for easier detect ui (created libzypp, not handy by user) lock can be special attribute added to query which has also be written to file during serialize and libzypp after session (or after confirm lock etc.) can remove only query with this argument. So ui can use more complicated locks

Hmm. If we want to somehow classify locks/queries and save this to a file, we could think about supporting tags(keywords): (YAST-SWSINGLE) lockspec... // generated by sw_single lockspec.. // by user (mygames,mykde) lockspec.. // by user, tags assigned (mygames) lockspec.. // " -- 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