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