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