[zypp-devel] Locks wiki
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr). Pepa [1] http://en.opensuse.org/Libzypp/Locksfile -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Apr 24, 2008 at 04:23:25PM +0200, Josef Reidinger wrote:
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr).
Thanks for putting that in the wiki. Some comments: 1) I don't think you should support "global_string" at all. I don't see any real-life use case. 2) IMHO the default should not be "substring", but "exact". The default should also not be case sensitive. (please use least surprising defaults) 3) I think we no longer support atom/message/script kinds. 4) I'm not sore we really need that "solvable_" prefix. It just makes things hard to read. 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
Michael Schroeder wrote:
On Thu, Apr 24, 2008 at 04:23:25PM +0200, Josef Reidinger wrote:
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr).
Thanks for putting that in the wiki.
Some comments:
1) I don't think you should support "global_string" at all. I don't see any real-life use case.
2) IMHO the default should not be "substring", but "exact". The default should also not be case sensitive. (please use least surprising defaults)
3) I think we no longer support atom/message/script kinds.
4) I'm not sore we really need that "solvable_" prefix. It just makes things hard to read.
Cheers, Michael.
Thanks for responses. 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. 2) jano think that regex can be default. Problem is that query have default substring so it must have some hack to change it (and have some real problems with it - like if I read query and it have search by substring - is this substring users substring or it is default value and change it to regex?). maybe you overlook case-sensitive, but default is !in!sensitive 3) I write documentation from code, If we don't support it. I remove it from documentation. 4) This is serious problem. When I propose api I have two ways a) have flexible implementation which uses SolvAttr for reading, so when someone extend SolvAttr Locks automatic support it. b) have own variables which I translate to SolvAttr which uses PoolQuery. When SolvAttr change, I must also change locks variables. also translate from own Attribute to/from solvAttribute is non-trivial (but possible). I decide use way a). But this result in using solvable names (only replace/:/_). If every Solvable attributes uses solvable prefix I easy can add it and remove it, but they also have update prefix and some hasn't prefix, so this is not possible. I see two ways - 1) change names in knowid.h (in sat-solver) 2) change implementation to b) with all negatives any other idea how can I solve it? Pepa -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
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
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
Michael Schroeder wrote:
On Thu, Apr 24, 2008 at 04:23:25PM +0200, Josef Reidinger wrote:
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr).
Thanks for putting that in the wiki.
Some comments:
1) I don't think you should support "global_string" at all. I don't see any real-life use case.
It's just for convenience: you can search for "foo" in three attributes like this: global_string: foo attr1: attr2: attr3: (is the ':' needed here btw?) or like this: attr1: foo attr2: foo attr3: foo I just would pick up the keywords more carefully: global_string -> query_string or match_string? kind -> package_type (or just 'type') - people don't need to know what do we mean with 'kind' all_require -> require_all install_status - we should not support this in a lock file at all - nobody would expect what it actually does. string_type -> match_type
2) IMHO the default should not be "substring", but "exact". The default should also not be case sensitive. (please use least surprising defaults)
4) I'm not sore we really need that "solvable_" prefix. It just makes things hard to read.
I agree here. I'd suggest to make the locks file more human friendly and use some Locks2Query adapter that would translate locks file entries to a PoolQuery. E.g. this solvable_foo attribute name is a "solvable:name" attribute id as defined in SolvAttr.h of libzypp (knownid.h of libsatsolver). We could use a simple "name: foo" instead of "solvable_name: foo", and the Locks2Query would translate it accordingly. It would need a mapping from these locks file attributes to SolvAttr attribute names. We could even use the old format (extended by a kind) with Locks2Query, but that way we would loose all the possibilities the PoolQuery offers (regexes/globs, multiple search strings (TODO:O) multiple attributes, search by deps, etc...). The Locks2Query would solve also problem 2) (although that particular default could be changed in the PoolQuery itself). (BTW, maybe we should also clean up/unify the SolvAttr/knownid.h attribute names a bit as well. And while i'm at it: any idea how to enable PoolQuery to search in dependencies? It works now by using e.g. addAttribute("solvable:requires"), but you see that is not an ideal state. What about adding these dependency attributes to SolvAttr.h just like i added "solvable:name" there? :O)) Cheers, jano -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Hi, On Wed, 30 Apr 2008, Jano Kupec wrote:
We could even use the old format (extended by a kind) with Locks2Query, but that way we would loose all the possibilities the PoolQuery offers (regexes/globs, multiple search strings (TODO:O) multiple attributes, search by deps, etc...).
At least some of these could be expressed with flags like your usual regexps: bla/i (case insensitive), bla*/g (glob), bla.*/r (regexp), bla/d (search in deps), bla/s (seach in all solvable attributes (nevra+deps) and so on. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jano Kupec wrote:
Michael Schroeder wrote:
On Thu, Apr 24, 2008 at 04:23:25PM +0200, Josef Reidinger wrote:
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr).
Thanks for putting that in the wiki.
Some comments:
1) I don't think you should support "global_string" at all. I don't see any real-life use case.
It's just for convenience: you can search for "foo" in three attributes like this:
global_string: foo attr1: attr2: attr3: (is the ':' needed here btw?)
or like this:
attr1: foo attr2: foo attr3: foo
I just would pick up the keywords more carefully:
global_string -> query_string or match_string? kind -> package_type (or just 'type') - people don't need to know what do we mean with 'kind' all_require -> require_all install_status - we should not support this in a lock file at all - nobody would expect what it actually does. string_type -> match_type
Strings changes in commit 9958. global_string -> query_string kind->type all_require - only mistake in wiki, in code is require_all string_type -> match_type
2) IMHO the default should not be "substring", but "exact". The default should also not be case sensitive. (please use least surprising defaults)
4) I'm not sore we really need that "solvable_" prefix. It just makes things hard to read.
I agree here. I'd suggest to make the locks file more human friendly and use some Locks2Query adapter that would translate locks file entries to a PoolQuery.
E.g. this solvable_foo attribute name is a "solvable:name" attribute id as defined in SolvAttr.h of libzypp (knownid.h of libsatsolver). We could use a simple "name: foo" instead of "solvable_name: foo", and the Locks2Query would translate it accordingly. It would need a mapping from these locks file attributes to SolvAttr attribute names.
We could even use the old format (extended by a kind) with Locks2Query, but that way we would loose all the possibilities the PoolQuery offers (regexes/globs, multiple search strings (TODO:O) multiple attributes, search by deps, etc...).
The Locks2Query would solve also problem 2) (although that particular default could be changed in the PoolQuery itself).
Locks2Query mean that we need own string translations. This mean another lines of code, potential bugs. Also it break behavior that locks is only PoolQuery which locks result. If we make UsersReadablequery<->query translation it mean, that sat-solver uses bad string and if sat-solver is only library which we must use and cannot change is OK use facade, but when we can change sat-solver, why don't use friendly string on low level? It looks little ineffective if we have string from user and must translate it to use it in sat-solver (and I don't see any reason why sat-solver must use this strings instead of another). But translator have advantage that we can support some old strings and convert it to new one so it separate user string from solver-strings. Pepa
(BTW, maybe we should also clean up/unify the SolvAttr/knownid.h attribute names a bit as well. And while i'm at it: any idea how to enable PoolQuery to search in dependencies? It works now by using e.g. addAttribute("solvable:requires"), but you see that is not an ideal state. What about adding these dependency attributes to SolvAttr.h just like i added "solvable:name" there? :O))
Cheers, jano
-- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Hi, On Tue, 6 May 2008, Josef Reidinger wrote:
Locks2Query mean that we need own string translations. This mean another lines of code, potential bugs. Also it break behavior that locks is only PoolQuery which locks result.
If we make UsersReadablequery<->query translation it mean, that sat-solver uses bad string and if sat-solver is only library which we must use and cannot change is OK use facade, but when we can change sat-solver, why don't use friendly string on low level?
They are friendly already to my eyes :-) Much more friendly than strings containing underscores. But these are esthetics which could be discussed endlessly, the end result is that satsolver potentially uses different strings than the Query. We can't change satsolver strings that often (would break the .solv files every time), so whenever someone comes up with a nicer string for the user we would have to add the translation anyway. Ciao, Michael. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Josef Reidinger wrote:
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr).
Pepa
[1] http://en.opensuse.org/Libzypp/Locksfile I also noticed the source code has no documentation at all. I suggest to document the functions and in the class documentation, link to the wikipage.
Duncan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Duncan Mac-Vicar Prett wrote:
Josef Reidinger wrote:
Hi, I create wiki page[1] about locks format. Please fill info about solvattr which i don't know. One interesting thing is, that locks accept everything from knowid from sat-solver, because I pass string with attribute to poolquery and poolquery fill this string to dataiterator which know it. so also much undocumented attributes work (e.g. provides or evr).
Pepa
[1] http://en.opensuse.org/Libzypp/Locksfile I also noticed the source code has no documentation at all. I suggest to document the functions and in the class documentation, link to the wikipage.
Duncan
I will document the source code soon. j. -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (5)
-
Duncan Mac-Vicar Prett -
Jano Kupec -
Josef Reidinger -
Michael Matz -
Michael Schroeder