[Rpm-ecosystem] Rich deps syntax finalization

[Florian Festi]

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.

> 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)

or with C-like syntax

Requires: (langsupport-es ? foo-lang-es)
requires: (foo-lang-es | foo-lang-generic)

So the else/: part is a pretty thin coating of syntactic sugar.

> 
> or
> 
> Requires: (langsupport-es ? foo-lang-es : %{nil})
> 
> 
> if you don't have alternative to install. Of course this would imply 
> that also something like the following is allowed:
> 
> Requires: (1 ? foo-lang-es : foo-lang-generic)
> 
> Requires: (0 ? foo-lang-es : foo-lang-generic)
> 
> Requires: (%{nil} ? foo-lang-es : foo-lang-generic)

Well, we talked about TRUE and FALSE constants but concluded that they
should not be needed. So far I did not see the rich deps as a way to
quickly adjust the spec file. Note that these operators are evaluated
during dependency checking/solving. The names are looked up in the
transaction (and the version compare is done). If there are a match the
terms becomes TRUE otherwise FALSE. The operators then only work with
those. Of cause this would allow the use of TRUE/FALSE or 1/0 as
constants. BUt I am not sure we need them and I'd rather add them later
if there is real demand.

For adjusting the spec files %if is probably better suited as it keeps
things within the spec and does not leak into the dependencies and the
binary rpms.

>> 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.
> 
> Isn't true that Requires, BuildRequires etc are actually case 
> insensitive? Wouldn't this be first case sensitive thing in RPM?

Well, one could argue that. Otoh are the relations themselves case
sensitive.

Florian

-- 

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