Re: [Rpm-ecosystem] Rich deps syntax finalization

[Florian Festi]

On 10/18/2016 05:23 PM, Pat Riehecky wrote:
> Can a link to http://rpm.org/wiki/PackagerDocs/BooleanDependencies be
> added to
> http://www.rpm.org/wiki/PackagerDocs/Dependencies ?

Good point. Done!

Florian


-- 

Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Paul Argiry, Charles Cachera, Michael Cunningham,
Michael O'Neill
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Pat Riehecky]

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



___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Florian Festi]

On 09/01/2015 02:20 AM, Neal Gompa wrote:
> On Mon, Aug 31, 2015 at 10:14 AM, Florian Festi  >wrote:
> 
> My thought after the discussion so far:
> 
> May be no one really cares about the syntax.
> Still a lot of educating to do before rich deps go into production.
> 
> 
> On 08/25/2015 02:11 PM, Florian Festi wrote:
> 
> > IF Operator
> 
> Guess we stay with (. IF . ELSE .) - even some people are more familiar
> with (. ? . : .).
> 
> > 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 am now tending to actually *use lower case*. This is what most
> programming languages do. May be familiarity beats emphasizing the
> operators with CAPS.
> 
> So (. if . else .)
> 
> 
> ​This makes sense. After all, the parenthesis al​ready denotes that the
> if/else clauses are meaningful.
> 
>  
> 
> > AND and OR
> > ==
> 
> I think we go for "and" and "or" for consistency. In the end it is
> really close with | and & to stay with dpkg. What pushed it over to and,
> or was having a different but consistent style for the rich deps - in
> opposite to macros and version comparisons.
> 
> 
> ​I'm okay with this.​ Will "or" have an ordering component (and thus,
> short-circuit logic capability from left to right)? Or will it remain
> order-less and fully evaluated each time?

For dependency checking (which is what rpm does) there is no difference
between short circuit and full evaluation.

Libsolv - the currently only dependency solver with rich deps support -
does not order the "or" terms but instead tries to pick the "best" of
all packages - no matter of the order within the dependency.

While we have discussed about adding this there are several reasons not to:

 * We have Suggests and Enhances which can be used to state package
preferences
 * The semantic is not that clear if you have nested expressions
 * Especially in combination with Suggests and Enhances
 * The implementation may be tricky as the rules get normalized to
conjunctive normal form before solving

> > NOT not?
> > 
> 
> NOT is confusing people and they have problems coming up with real use
> cases. So we will go without for now and reconsider when real need
> arises.
> 
> 
> ​What would you consider real use cases? ​
Well, an existing packages with needs to solve an issue but has trouble
doing so without the NOT operator. I would even accept if writing the
dependency without NOT is more cumbersome.

But so far I have not seen a single existing package that would actually
benefit.

> Speak now or forever hold your peace.
> 
> 
> ​I think this counts as speaking. ;)​
> 
>  
> 
> 
> 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
> 
> 
> 
> 
> -- 
> 真実はいつも一つ！/ Always, there's only one truth!
> 
> 
> ___
> Rpm-ecosystem mailing list
> Rpm-ecosystem@lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
> 


-- 

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
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Michael Schroeder]

On Tue, Sep 01, 2015 at 08:54:03AM +0200, Florian Festi wrote:
> Libsolv - the currently only dependency solver with rich deps support -
> does not order the "or" terms but instead tries to pick the "best" of
> all packages - no matter of the order within the dependency.
> 
> While we have discussed about adding this there are several reasons not to:
> 
>  * We have Suggests and Enhances which can be used to state package
> preferences
>  * The semantic is not that clear if you have nested expressions
>  * Especially in combination with Suggests and Enhances
>  * The implementation may be tricky as the rules get normalized to
> conjunctive normal form before solving

Note that debian does use the "or" order to specify preferences,
so when at some point far far in the future debian uses libsolv as
their dependenct solver, I'll have to implement this feature...

Cheers,
  Michael.

-- 
Michael Schroeder   m...@suse.de
SUSE LINUX GmbH,   GF Jeff Hawn, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Neal Gompa]

On Mon, Aug 31, 2015 at 10:14 AM, Florian Festi  wrote:

> My thought after the discussion so far:
>
> May be no one really cares about the syntax.
> Still a lot of educating to do before rich deps go into production.
>
>
> On 08/25/2015 02:11 PM, Florian Festi wrote:
>
> > IF Operator
>
> Guess we stay with (. IF . ELSE .) - even some people are more familiar
> with (. ? . : .).
>
> > 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 am now tending to actually *use lower case*. This is what most
> programming languages do. May be familiarity beats emphasizing the
> operators with CAPS.
>
> So (. if . else .)
>
>
​This makes sense. After all, the parenthesis al​ready denotes that the
if/else clauses are meaningful.



> > AND and OR
> > ==
>
> I think we go for "and" and "or" for consistency. In the end it is
> really close with | and & to stay with dpkg. What pushed it over to and,
> or was having a different but consistent style for the rich deps - in
> opposite to macros and version comparisons.
>

​I'm okay with this.​ Will "or" have an ordering component (and thus,
short-circuit logic capability from left to right)? Or will it remain
order-less and fully evaluated each time?


>
> > NOT not?
> > 
>
> NOT is confusing people and they have problems coming up with real use
> cases. So we will go without for now and reconsider when real need arises.
>
>
​What would you consider real use cases? ​



> Speak now or forever hold your peace.
>

​I think this counts as speaking. ;)​



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


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Florian Festi]

My thought after the discussion so far:

May be no one really cares about the syntax.
Still a lot of educating to do before rich deps go into production.


On 08/25/2015 02:11 PM, Florian Festi wrote:

> IF Operator

Guess we stay with (. IF . ELSE .) - even some people are more familiar
with (. ? . : .).

> 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 am now tending to actually *use lower case*. This is what most
programming languages do. May be familiarity beats emphasizing the
operators with CAPS.

So (. if . else .)

> AND and OR
> ==

I think we go for "and" and "or" for consistency. In the end it is
really close with | and & to stay with dpkg. What pushed it over to and,
or was having a different but consistent style for the rich deps - in
opposite to macros and version comparisons.

> NOT not?
> 

NOT is confusing people and they have problems coming up with real use
cases. So we will go without for now and reconsider when real need arises.

Speak now or forever hold your peace.

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
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Nick Coghlan]

On 26 August 2015 at 20:13, Vít Ondruch vondr...@redhat.com wrote:
 Dne 25.8.2015 v 17:16 Florian Festi napsal(a):
 On 08/25/2015 02:50 PM, Vít Ondruch wrote:
 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.

The two main options being considered are essentially Python-style
or C-style:

Python: (true_result if condition else false_result)
C: (condition ? true_result : false_result)

The key for me is that given the text:

Requires: (foo-lang-es IF langsupport-es ELSE foo-lang-generic)

any developer that can read both English and RPM spec files is likely
to be able to hazard a good guess as to what that will do, as it's an
abbreviation of the sentence This package Requires foo-lang-es IF
langsupport-es is provided, ELSE it requires foo-lang-generic. Even
if a developer does need it explained to them the first time they see
it, the sentence form is still useful as a mnemonic.

By contrast, the only way to know what Requires: (langsupport-es ?
foo-lang-es : foo-lang-generic) means is to be a C developer, or to
know one of the languages that borrowed that syntax from C - it isn't
possible to reason it out just by knowing English.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[James Antill]

On Wed, 2015-08-26 at 10:29 +0200, Florian Festi wrote:
 On 08/25/2015 06:12 PM, Pavel Odvody wrote:
  On Tue, 2015-08-25 at 18:01 +0200, Florian Festi wrote:
  Well, as Requires are (logically) all connected with an AND this is
  equivalent to:
 
  Requires: PkgA
  Requires: (PkgB IF NOT PkgC)
 
  And as IF is equivalent to OR NOT this is equivalent to
 
  Requires: PkgA
  Requires: (PkgB OR PkgC)
 
  This is  a great remark - Arguments are short-circuit evaluated.
 
 Short-circuit evaluation is a concept that has no meaning here.
[...]
 Short-circuit evaluation means some sub expressions are not looked at at
 all. But this is only relevant if evaluating some expressions can have
 side effects.

 But there is a side effect, something might be installed/removed. And
there will be expectations based on what is seen (so I suspect that your
first statement is wrong ... as the expectations will be different).
 Eg.

pkgA: Requires: pkgB IF NOT pkgC

...or:

pkgA: Requires: pkgC OR pkgB

...now what happens:

pkgA: To be installed
pkgB: NOT installed
pkgC: installed
if: pkgA will now not allow pkgC to be removed, without installing pkgB.
or: pkgA will now not allow pkgC to be removed, without installing pkgB.

pkgA: To be installed
pkgB: installed
pkgC: installed
if: pkgB and pkgC can't be removed, but either one can.
or: pkgB and pkgC can't be removed, but either one can.

...these look the same, right? But:

pkgA: To be installed
pkgB: installed
pkgC: NOT installed
if: pkgA will now not allow pkgB to be removed, without removing pkgA.  
In theory pkgC can be installed ... but I doubt many would predict
that outcome.
or: pkgA will now not allow pkgB to be removed, without installing pkgC.

pkgA: To be installed
pkgB: NOT available
pkgC: NOT installed
if: pkgC is installed, and user is confused.
or: pkgC is installed.

pkgA: To be installed
pkgB: NOT installed
pkgC: NOT installed
if: pkgB should be installed. Installing pkgC is technically legal but
would be a _big_ surprise, I think. Installing both would be lol.
with short circuit:
or: pkgB should be installed. Installing pkgC is technically legal but
would be a surprise. Installing both would be weird.
without short circuit:
or: pkgB or pkgC should be installed. Having both be installed would be
weird.

...of course IF has similar problems with:

pkgA: Requires: pkgB IF pkgC

...and what happens when you remove pkgB later (can remove pkgA or pkgC,
and I would guess the closest to the correct answer is: remove pkgA
unless pkgC was installed after pkgA).
 A decent amount of this is mitigated due to users not removing things
much, although the DNF autoremove leaf defaults will make that worse.

  As the matching does not have side effects you cannot tell
 from outside whether the implementation uses short circuit evaluation or
 not. So it is an implementation detail that's not your business.

 You can tell what happens when you install and/or remove things.
 I know the DNF maintainers currently hope that they can get away with
an undocumented compare_providers, and this would be a huge extension of
that, but I don't think they can.

___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem

Re: [Rpm-ecosystem] Rich deps syntax finalization

[Florian Festi]

On 08/26/2015 02:58 PM, Vít Ondruch wrote:
 Dne 26.8.2015 v 14:00 Florian Festi napsal(a):
 On 08/26/2015 10:47 AM, Florian Festi wrote:
 Right now libsolv does not distinguish between different orders of the
 operands. But we have already discussed making the OR operator
 preferring the left most operand. This is something RPM does not really
 care about but of cause has implications for packaging if implemented in
 libsolv.
 May be I should append to this slightly:

 AFAIK libsolv uses the Suggests: and Enhances: to pick one of *equally
 adequate* packages. But we stil need to gain more experience on how well
 this works.
 
 This works flawlessly for rubypick as far as I can say:
 
 http://pkgs.fedoraproject.org/cgit/rubypick.git/tree/rubypick.spec#n10

Good to hear!

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
___
Rpm-ecosystem mailing list
Rpm-ecosystem@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-ecosystem