Mailinglist Archive: zypp-devel (226 mails)

[Michael Schroeder <mls@xxxxxxx>]

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@xxxxxxx
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@xxxxxxxxxxxx
For additional commands, e-mail: zypp-devel+help@xxxxxxxxxxxx