Ok, it looks like a lot of people are having trouble with the semantics
of the rich deps operators. I'll try a short introduction:

Requires, Recommends, Suggests, Supplements, Enhances and Conflicts are
all matched against the Provides.

With the new rich deps Provides stay the way they are (NAME FLAGS
VERSION) while all the other relations can use the new Boolean operators.

Right now Requires: are matched against the Provides: and if no match is
found an error is issued. With rich deps we do the same matching but
instead of jumping to conclusions we create a Boolean value: TRUE if
there is a match FALSE if there isn't. All rich deps operators are
Boolean operators[1] working on these Boolean values. For

Requires: (pkgA | pkgB)

We search for matches for pkgA and pkgB and then combine the truth
values with OR. If the result is FALSE we create an error as Requires
need to be TRUE (Conflicts need to be FALSE). As this is all Boolean
algebra the operators can be nested arbitrarily. E.g.

Requires: (pkgA | (pkgB & pkgC))

The same way is the IF/? operator just a Boolean operator. The suggested
IF and ? use different order of the operands but are other wise the
same. They are equivalent to the following - may be more familiar
operators (dots representing the operands).

(. IF .) (. OR NOT .) (. <- .) aka Converse implication [2]
(. ? .)  (NOT . OR .) (. -> .) aka Material implication [3]

If the very same way would the NOT operator inverse the Truth value of
its operand:

(NOT pkgA) is TRUE if there is no match. But NOT could also be used to
negate larger expressions.

As (NOT pkgA) equivalent to Conflicts: pkgA. Having the NOT operator
would allow "using Conflicts" in more complicated Requires: statements. E.g.

Requires: (pkgA | (pkgB AND NOT pkgC))

Which "means" pkgB can be used as an alternatve to pkgA if pkgC is not
installed. But you can also just do the Boolean calculation for given
set of matches.

If you step back a bit things are still the same old same old. Rpm
checks if Requires are fulfilled and there are no Conflicts by matching
and calculating the Boolean values (and issues errors if needed). And
Libsolv will actually figure out what packages need to be added (or
removed) to make the Requires: TRUE and the Conflicts: FALSE (and handle
all the weak deps).

I hope this clears things up a little bit.

Florian

[1] https://en.wikipedia.org/wiki/Truth_function
[2] https://en.wikipedia.org/wiki/Converse_implication
[3] https://en.wikipedia.org/wiki/Material_conditional

-- 

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

Reply via email to