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

Michael Matz wrote:

Hi,

On Thu, 27 Mar 2008, Josef Reidinger wrote:

...

- 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

This doesn't work. Suppose you have a lock matching "a*", then it currently applies to a certain set of solvables (those starting with 'a'). If you write out locks for exactly that set you miss the case if the user installs another package starting with 'a'. The old lock would have applied to it, the set of new locks wouldn't anymore. Not to talk about the waste of course.

Perhaps the two file idea is the cleanest.

OTOH I don't really see the necessity of two files. Suppose again there is a "a*" lock that zypp loads (and remembers, so it also can be stored back). Further suppose that the user now explicitely locks a package abcde (matching the regex lock). There's no reason why zypp should also store that lock too (so that in the end the lock file will contain "a*" and "abcde"). By this way you don't need to become overly fancy in order to not store superflous locks (i.e. I want to say that the complication in your first point seems unnecessary to me).

Ciao, Michael.

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. And this solve my sollution, which check if regex set of locked package is subset of really locked package. So you see, that a* cannot survive, because user want unlock abcd package. So expand is needed. (for example yast can popup warning after unlock (see fuction matchingLocks in api) which return what lock must be removed and expanded. Two files doesn't solve this problem (user must edit user locks file to remove a*). Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Matz wrote:

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

Well, I used to lock my kde packages to have a working desktop using kde*, and as every path goes to Rome^H^H^H^Hsome gtk or gnome stuff that ends with evolution and nautilus in, I usually lock those from being installed by doing some gnome wildcard (not on all my computers anyway). Also I can imagine a webserver with a rails app would like to lock all rubygems* to avoid breakage. Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

On Thu, Mar 27, Stanislav Visnovsky wrote:

What should happen with locks during system upgrade?

Ask the user? - mounting target - reading targets zypp.conf (to get target related paths and settings. we can't do this by now) - check whether locks are on and defined - ask the user whether to use them during update, or ignore them. if use: load the locks and write them back on commit. if ignore: no load no write back -- 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

Michael Andres wrote:

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 ProcessResolvable;

This in IMO the least usefull item here (ResObject::Ptr). Query should 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). 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). So is not better returns PoolItem instead of solvable? Or I overlook something?

thanks, Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

...

...

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

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 ( I think it create it, for example name and kind...maybe also repo...whatever ) and is easy recognize who make this query. And users lock can be removed only handy by user (of course some warning for users, that this behavior is used). somethink like manually generated: yes|no (default no...we can secure that we write only yes). maybe this can be also used in future for some query history (user can write own query which doesn't remove libzypp from history) so he can store install result of his own query (f.e. he is developing and need last version of some libs so he can write manual query and then only each week write something like zypper up --query myquery and update only result of this query....hmm...only idea for future use Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org

Michael Andres wrote:

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.

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

...

and <

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