Michael Schroeder wrote:
On Fri, Apr 25, 2008 at 08:21:34AM +0200, Josef Reidinger wrote:
1) idea behing locks is that it lock everything which can be result of search. So it use serialized query. Jano have this string in PoolQuery so I also support it. I can undocument it and have it only as undocumented feature with no guarantee or support.
There are some other implications of using a generic search interface for locks that should be taken into account:
The "glue code" to the solver is not simple. It makes no sense to just build locks from the solvables returned by the search. Here is why: Say you have a lock in "solvable_name: libfoo", and packages libfoo-1-1 libfoo-1.2 libfoo-1.3 matches. If you create a lock for each package and some other selected package needs libfoo, the solver will offer three different problem solutions: "remove lock for libfoo-1-1", "remove lock for libfoo-1-2", and "remove lock for "libfoo-1-3". Thus, the glue code has to translate the search result back to "lock solvables with name libfoo".
thats quite problem. Does we have some more universal locking mechanism then by solvables? If yes I can analyze query and use this better lock. BTW. How YaST in 10.3 lock files? which call? does they have some high-level call?
You obviosly have to redo your lock searches if a repository is added/removed/refreshed.
it is one call apply() (if you have own changes to locks then you must save it first). Again do we have any better locking mechanism then by solvable? How do you handle the case if the
user removed some lock due to some solving problem?
add query which specify what you unlock. Then if match locking query remove matching query, if not ask user if remove old or ignore new (if he want something other he must again lock something if removing old unlock something, but to have unlock this new unlocked package, he must better specify what exactly lock)
This is a genreic problem: How do the locks created by the search mix with the locks from the user interface? If I change some lock with the UI, is the lock file changed?
yes, by method which I describe upper. If you use only UI locks, then everything is fine. If you mixed locks from different source you must choose if let live old lock or remove it. And if remove unlock something which you don't want, that you must precise specify what you want lock. this all is done only during save to file.
To sum up, I'm not sure if locks done by generic searches are really a good idea.
I welcome better ideas
Regarding case sensitivity, I meant that the search should be case sensitive. rpm names are case sensitive, so that's what people expect.
I talk with jano what they think about it.
Cheers, Michael.
Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org