[Rpm-ecosystem] Rich deps syntax finalization
ngompa13 at gmail.com
Wed Aug 26 10:13:23 UTC 2015
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
> 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
> 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.
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Rpm-ecosystem