On Apr 23, 2012, at 10:32 AM, Jeff Johnson wrote:
> I should point out that writing the attached
> message (and sending from the wrong e-mail address) has instantly
> led to a different -- and perhaps more natural -- syntax like
>
> Requires: set(libfoo.so.1) >= whatever
>
After a month of quietly muddling, I like this namespace like syntax
better because it doesn't lead to magic tokens like "set:" in the EVR
string and is more consistent with existing namespaces in RPM dependencies.
I'll leave the existing "set:" prefix as is until I implement the set(…) syntax.
> for set:versions, and for the generalization (for writing strict regression
> tests,
> its mostly useless in packaging because there is no mapping that specifies
> how the mixed DEB <-> RPM version comparison might be done "naturally")
>
> Requires: deb(foo) >= E:V-R
> Requires: rpm(foo) >= E:V-R
>
(aside)
And this is a rather easy/natural extension to choose between alternative
version comparisons (at least for development/testing).
OTOH, its mostly useless for dependency assertion evaluation because there
is no clearly identified "mixed" comparison when
Provides: deb(foo) >= E:V-R
Requires: rpm(foo) >= E:V-R
I suppose I can attempt a resolution like this
Prefer an explicit comparison in the Provides: if there is a conflict.
Prefer an explicit comparison over an implicit/default comparison
Use the default comparison if no explicit comparison hint is present.
> The precedent for foo(bar) name spacing in RPM dependencies with
> the above syntax is already widely deployed although entirely
> de facto.
>
> Sure would be nice _NOT_ to have to consider "Have it your own way!"
> competing syntaxes like
> Requires: libfoo.so.1 >= set:whatever
> and
> Requires: set(libfoo.so.1) >= whatever
> (and I'll ignore the gawdafulness of existing multilib dependencies like
> Requires: libfoo.ao.1()(64bit)
> coming along rapidly as a Newer! Better! Bestest! ABI standard now
> that there is support in kernel >= 3.2.
>
> *shrug*
>
> Its all implementable, just not very KISS when aesthetic/innate opinions get
> involved.
>
OK, I'm in the last stages of adding twiddle-in-version so its time to consider
other changes:
1) Epoch as a string? The only lossage here is when digit strings
differ in length
(and strcmp isn't identical to arithmetic comparison). Alternatively,
should Epoch's
be forced to a [0-9]+ digit string?
2) Is there a need for
twiddle-in-epoch(assuming a string)
twiddle-in-release
twiddle-in-distepoch
There are/were several ways to implement twiddle-in-version; so far I've
chosen to do only twiddle-in-version because that involved little more
than rewriting some regex patterns. OTOH, handling twiddle-in-version
as a special case of a more general string comparison (aka rpmvercmp)
is at least as much of a problem as just permitting the full
generalization.
3) revisiting dependency ranges with syntax like this
Provides: foo = [1.2-3|4.5-6)
which would match only Requires in the range, including 1.2-3 because
of the '['
and excluding 4.5-6 because of the ')' with the usual mathematical
conventions (in the US).
The problematic character would be choosing a separator (I used '|' in
the example): almost
all the usual characters have pre-existing usages, but perhaps
something could still be twitched together.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
