Mailinglist Archive: zypp-devel (227 mails)
|< Previous||Next >|
Re: [zypp-devel] api proposal for locks
- From: Josef Reidinger <jreidinger@xxxxxxx>
- Date: Tue, 01 Apr 2008 18:15:31 +0200
- Message-id: <47F25FA3.5010503@xxxxxxx>
---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?
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.
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).
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
To unsubscribe, e-mail: zypp-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx
|< Previous||Next >|