Mailinglist Archive: zypp-devel (226 mails)

[Jano Kupec <jkupec@xxxxxxx>]

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