[Rpm-ecosystem] Rich deps syntax finalization

Neal Gompa ngompa13 at gmail.com
Wed Aug 26 10:42:58 UTC 2015

On Wed, Aug 26, 2015 at 6:13 AM, Neal Gompa <ngompa13 at gmail.com> wrote:

> On Wed, Aug 26, 2015 at 4:47 AM, Florian Festi <ffesti at redhat.com> wrote:
>> On 08/25/2015 06:58 PM, Neal Gompa wrote:
>> > I consider the NOT evaluation to be useful for intent more than anything
>> > else.
>> >
>> > For example: "Requires: (pkgA IF NOT pkgB)" or "Requires: (IF NOT pkgB
>> > THEN pkgA)"
>> > That lines says two things to me:
>> >
>> >   * The package prefers pkgB over pkgA
>> >   * Either option works (functionally an OR operation)
>> >
>> > This could be handy for declaring priority of dependencies based on what
>> > functionality it provides.
>> >
>> > For a more concrete example, suppose I have a package that has a runtime
>> > dependency on a kmod package. However, the kmod package is available in
>> > several forms (akmod, dkms, and finally kmod). I could set up something
>> > like this:
>> >
>> > "Requires: (IF NOT (IF NOT module-kmod THEN module-akmod) THEN
>> > module-dkms)"
>> >
>> > ​If read with the intent given, then that means that if module-kmod
>> > isn't installable, then use module-akmod. If that's not installable,
>> > then use module-dkms.
>> >
>> > Or maybe I'm misreading how this would work, but that's how I interpret
>> it.
>> You are actually not that far from the truth:
>> As (. IF  .) is equivalent to (. OR NOT .) (. IF NOT .) is  equivalent
>> to (. OR .). So you are writing things more complicated than needed. You
>> can just write (module-kmod OR module-akmod OR module-dkms). This is
>> exactly the same.
>> 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.
>> 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
> ​Well, my assumption was that OR doesn't have short-circuit logic in
> place, or that it has a particular ordering. The logic I wrote technically
> enforces the order by explicitly declaring how I want the resolution to
> take place. It's essentially more expressive than just saying "Requires:
> (module-kmod OR module-akmod OR module-dkms)".​ The three-term OR statement
> does not make it obvious what the preference actually is.
> I think there's a place for having equally weighted ordering as well as
> priority oriented ordering. There are circumstances where either one could
> be useful. The intent is also important if the user has none of the
> providers installed already. If one of them is already installed, obviously
> we shouldn't install something new, but if none of the Requires are
> satisfied by the package set already installed, then it should pick one or
> bomb out depending on what you want it to do.
​Actually, I want to append to this slightly. I would expect that an equal
weighted OR Requires would be depsolved by choosing the dependency that
drags in the fewest dependencies unless the user explicitly suggests

真実はいつも一つ!/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-ecosystem/attachments/20150826/35791592/attachment-0001.html>

More information about the Rpm-ecosystem mailing list