[Rpm-ecosystem] Rich deps syntax finalization

Florian Festi ffesti at redhat.com
Wed Aug 26 11:45:18 UTC 2015

On 08/26/2015 12:13 PM, Vít Ondruch wrote:
> Dne 25.8.2015 v 17:16 Florian Festi napsal(a):
>> On 08/25/2015 02:50 PM, Vít Ondruch wrote:
>>> Dne 25.8.2015 v 14:11 Florian Festi napsal(a):
>>>> 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.
>>> Do I understand it correctly, that the direction is different when
>>> you are using ELSE and without ELSE? E.g. for this case:
>>> Requires: (foo-lang-es if langsupport-es)
>>> I read it as "install foo-lang-es in case langsupport-es is
>>> installed". This is quite common construct, but I really don't
>>> understand the else case.
>>> Could you please read it for me? Especially the ternary operator 
>>> version, it looks like ternary operator but I am afraid it is not.
>> Requires: (foo-lang-es if langsupport-es else foo-lang-generic)
>> Requires: (langsupport-es ? foo-lang-es : foo-lang-generic)
>> These two variants are equivalent. Only the first two operands have
>> switched places in both the binary and the ternary version.
> The swapped order worries me. I have yet to see any language which
> supports the "[else .]" part of if condition in the backward order.
>>> Wouldn't it be better to have just the ternary operator syntax?
>> Nah. I guess most cases will just use the binary operator case. Note
>> that the above are equivalent to
>> Requires: (foo-lang-es if langsupport-es)
>> Requires: (foo-lang-generic or langsupport-es)
> And that these two lines above are supposed to be better readable then
> this oneliner?

> Requires: (langsupport-es ? foo-lang-es : foo-lang-generic)

Not at all. I was just giving an equivalent to make the semantic more
clear. The reason why we added the ternary operator is because it is
easier to understand and easier to write. The above just demonstrates
that the ternary operators - while being convenient - are not strictly

> I might be slower, but I was starring at that two lines for a while,
> prior I realized that that two lines are equivalent to that one indeed.
> Moreover, one would expect that the foo-lang-generic will be always
> installed, since it should be evaluated first in case short-circuit
> evaluation.
> Now reading through the rest of discussion, I understand that there is
> AND between these two lines and the short-cicruit evaluation makes no
> sense, but
> 1) It is not documented and not obvious on first look
> 2) Who reads documentation anyway :)

1) Well, the AND between those lines is nothing new at all. Requires
need all to be fulfilled. Interpreting this as there being an AND
between the lines (as libsolv does internally) is just a different way
of saying the same thing.

> [1] http://rpm.org/wiki/PackagerDocs/BooleanDependencies

2) That's why I explain it on the mailing list



Red Hat GmbH, http://www.de.redhat.com/ Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael
O'Neill, Charles Peters

More information about the Rpm-ecosystem mailing list