And here's the answer to my own reply.
If you look at how rpmlib(...) dependencies are
implemented,
you will see how to package up Provides: and Requires: so
that the need for syntax for Provides: version ranges is
mitigated.
Basically, one needs to insure that the measure of the range
expressed
through an inequality is closed and finite.
A closed range happens quite naturally with Requires:
because of
the way logical assertions on inequalities work.
E.g.
Requires: foo > 1
Requires: foo < 2
is the closed range (using the usual mathematical notation)
(1:2)
i.e. end-points not included.
Still, what is commonly done in packaging is quite broken.
Consider
this dependency
Requires: kernel >= 2.6.9
That is an assertion on an open-ended range that assumes
that
whatever is desired from kernel-2.6.9 or later will remain
in the
kernel package forevermore. Not bloody likely imho.
If you look at rpmlib dependencies, the dependency on
functionality is expressed
within a name space (and so the N is always unique and has
nothing to do with
package names), and the range is closed because the
inequality is always bounded
from below. An example is perhaps in order:
Requires: rpmlib(Foo) <= 1
That inequality covers the closed range [0:1] (iusing
"0" to represent
an origin.
Now for Provides, which also can specify closed ranges as
Provides: foo <= 1
which is the same [0:1] range as previous example. In most
cases (all that
I can think of), there's no need to express a Provides: as
an inequality at
all, a single point is quite sufficient, and then use a
Requires: version range.
So
Provides: rpmlib(Foo) = 1
matches the previous Provides:.
If I ever have to change whatever rpmlib(Foo) is tracking,
then I
start to produce
packaging that looks like
Provides: rpmlib(Foo) = 2
and
Requires: rpmlib(Foo) <= 2
(if the change is forward compatible from previous), or add
an additional
Requires: rpmlib(Foo) > 1
if not compatible.
So the two rules are:
1) Always try to use closed ranges.
2) Use a non-package marker like rpmlib(...) to track
some functionality
explictly.
I hope that's clearer than mud.
Again what is really busted is that once a package goes out,
whatever
dependencies it left with must be dealt with, either by
re-rolling the
package (which just ain'y gonna happen), or by retro-fitting
dependencies
through a lookaside cache or (possibly) with an Enhances:
like mechanism.
(Note: I am not claiming that Enhances: would fix the
problems I describe.)
73 de Jeff
_______________________________________________
Rpm-devel mailing list
Rpm-devel lists.dulug.duke.edu
https://lists.dulug.duke.edu/mailman/listinfo/rpm-devel
|