[Rpm-ecosystem] Rich deps syntax finalization

Pat Riehecky riehecky at fnal.gov
Tue Oct 18 15:23:42 UTC 2016


Can a link to http://rpm.org/wiki/PackagerDocs/BooleanDependencies be 
added to
http://www.rpm.org/wiki/PackagerDocs/Dependencies ?


Pat

On 08/25/2015 07:11 AM, Florian Festi wrote:
> Hi!
>
> I have been visiting Michael Schröder discussing the syntax for the rich
> deps [1]. 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 [2].
>
> Forward:
> 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)
> Backward:
> Requires: (foo-lang-es if langsupport-es)
> Requires: (foo-lang-es IF langsupport-es)
> Requires: (foo-lang-es <- langsupport-es)
>
> With ELSE operand:
> Forward:
> Requires: (pkgB ? pkgA : pkgC)
> Requires: (pkgB ?? pkgA !! pkgC)
> Requires: (pkgB then pkgA else pkgC)
> Requires: (pkgB THEN pkgA ELSE pkgC)
> Backward:
> 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.
>
> 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.
>
> 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?
>
>
> Florian
>
>
> [1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies
> [2] 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 .)
>



More information about the Rpm-ecosystem mailing list