[Rpm-ecosystem] Rich deps syntax finalization

[Florian Festi]

On 08/26/2015 11:23 PM, James Antill wrote:
> 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:

Yup!

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

Not really seeing the difference here...
Note that things are much more clear if you look at the actual commands.
As dnf remove does just remove packages the install pkgC case is
normally not happening.

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

Yup.

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

You are looking at theses cases with the wrong model in mind. Unlike yum
libsolv is not processing this one term at a time. The rules derived
from the relations are normalized into a conjunctive normal form. Then
the best package for making the disjuctive term True is chosen. As both
of the above are just (pkgB OR pkgC) the normalized term is a OR term
with all candidates/matches of pkgB and pkgC. libsolv then picks the
"best" package no matter whether it matches pkgB or pkgC. (At least this
is my understanding of how the implementation works. But in the end what
matters is that you should not make assumptions how these expressions
are evaluated.)

So I repeat myself: Those two variant have exactly the same meaning. The
only thing that you may rely on is that the depsolver will pick a
solution that will make the whole term True.
Writing things in a funny was to influence what packages gets chosen
does not work.

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

This is indeed an interesting aspect. May be Pavel wants to add a few
test cases to clarify this. DNF autoremove should actually not trigger
this as it only works on packages no longer required not on dependencies
no longer fulfilled.

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

We'll see.
I'll rather invite people to use Suggests: and Enhances: to state the
preferences for one of the providers than to rely on some obscure
implementation details of the depsolver that will vanish as soon as the
transaction is a bit more complicated anyway.


In the end I more and more get the impression that Michael is right and
we should not add a NOT operator. At least until there is real demand
for it. People just get confused with what can, should and should not be
done with it.

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