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". You obviosly have to redo your lock searches if a repository is added/removed/refreshed. How do you handle the case if the user removed some lock due to some solving problem? 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? To sum up, I'm not sure if locks done by generic searches are really a good idea. Regarding case sensitivity, I meant that the search should be case sensitive. rpm names are case sensitive, so that's what people expect. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org