[Rpm-ecosystem] Rich deps syntax finalization
podvody at redhat.com
Tue Aug 25 15:54:48 UTC 2015
On Tue, 2015-08-25 at 14:11 +0200, Florian Festi wrote:
> I have been visiting Michael Schröder discussing the syntax for the rich
> deps . There are still a few issues we like to get some input from
> the wider community:
> IF Operator
> We concluded that the most important question was what to do with the if
> operator. There are two basic variants that can both be used with
> different symbols: forward and backward .
> Requires: (langsupport-es ? foo-lang-es)
> Requires: (langsupport-es ?? foo-lang-es)
> Requires: (langsupport-es then foo-lang-es)
> Requires: (langsupport-es THEN foo-lang-es)
> Requires: (langsupport-es -> foo-lang-es)
> Requires: (foo-lang-es if langsupport-es)
> Requires: (foo-lang-es IF langsupport-es)
> Requires: (foo-lang-es <- langsupport-es)
> With ELSE operand:
> Requires: (pkgB ? pkgA : pkgC)
> Requires: (pkgB ?? pkgA !! pkgC)
> Requires: (pkgB then pkgA else pkgC)
> Requires: (pkgB THEN pkgA ELSE pkgC)
> Requires: (pkgA if pkgB else pkgC)
> Requires: (pkgA IF pkgB ELSE pkgC)
> Semantics for all examples is: foo-lang-es/pkgA is needed if
> langsupport-es/pkgB is installed. pkgC is required instead if
> langsupport-es/pkgB is not installed.
> After a lengthy discussion we are pretty confident that the Python style
> (. IF . [ELSE .]) is the best choice. It gives a clear hint which
> direction the operator works and is more familiar than the implication
> arrows and THEN.
I like the backward syntax better, it nicely reads out:
Requires: (foo-lang-es IF langsupport-es)
"Requires foo-lang-es if langsupport-es" is almost valid English
sentence that correctly reflects what's going to happen.
The Python syntax should be generally most approachable for everybody,
on the other hand, if the operators are represented by characters that
are not really used elsewhere in the Spec they'll nicely stand out
> As I - as a Python programmer - am pretty biased I am very interested if
> programmers knowing only other languages or package maintainers without
> programming skills can relate to this decision.
> We discussed whether the operators should be upper or lower case or case
> insensitive. So far we think *upper case* is better as is stands out
> between the typically lower case package names. But we are interested on
> second opinions on this, too.
I think uppercase, so that it really stands out and the chance of
mistaking it for package name gets lower.
> AND and OR
> Assuming that (. IF . [ELSE .]) is chosen as syntax if the if operator
> we discussed how to represent AND and OR. We dropped || and && as dpkg
> uses | and having bitwise and logical operators at the same time does
> not make any sense in an rpm context - we are operating on true Boolean
> only there is no change of ints getting into this.
> In the end this is more or less a matter of taste. We tended to just
> stick to written out operators but in the end there is no strong case to
> make for any of them.
> So what syntax does feel most natural to you (most obvious pro arguments
> in parenthesis)
> [ ] AND and OR (easier to spot, aligned with IF and ELSE)
> [ ] & and | (aligned with dpkg and many programming languages)
> [ ] && and || (stress Boolean character)
> NOT not?
> We discussed whether to add a NOT operator. One of the reasons not to
> was that it is pretty awkward if used on the top level:
> Requires: (NOT pkgA)
> which is basically a Conflict
> or even:
> Conflicts: (NOT pkgA)
> which is basically a Requires
> Technically a NOT operator should not be needed. So we are basically
> looking for real life examples where it would be really handy or even a
> pain if it was missing. What would you do with a NOT operator?
Requires: (PkgA AND (PkgB IF NOT PkgC)
But I'm really not sure whether it isn't just easier (correct) to handle
this through conflicts / virtual provide.
>  http://rpm.org/wiki/PackagerDocs/BooleanDependencies
>  We are talking about Boolean operators here - not if statements.
> Those variants are identical to the forward and backward implication
> which are identical to (NOT . OR .) and (. OR NOT .)
Pavel Odvody <podvody at redhat.com>
Software Engineer - EMEA ENG Developer Experience
5EC1 95C1 8E08 5BD9 9BBF 9241 3AFA 3A66 024F F68D
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Rpm-ecosystem