[Rpm-ecosystem] Required version of rpm?

[Jeff Johnson]

> On Jun 29, 2018, at 8:27 AM, Miroslav Suchý <msuchy at redhat.com> wrote:
> 
> Dne 26.6.2018 v 15:57 Panu Matilainen napsal(a):
>> 
>> Nope. From my previous email: "the version in rpmlib() dependencies is sorta backwards to what people generally expect."
>> - but it's the range, not the version that appears backwards.
>> 
>> This is the way all rpmlib() dependencies have always been, here's the best explanation I've found:
>> 
>> https://www.redhat.com/archives/rpm-list/2001-April/msg00283.html
>> 
> 
> ???
> 
> in lib/rpmds.c there is:
> 
> static const struct rpmlibProvides_s rpmlibProvides[] = {
> ...
>    { "rpmlib(RichDependencies)",    "4.12.0-1",
> 
>        (               RPMSENSE_EQUAL),
>    N_("support for rich dependencies.") },
> 
> and indeed
>  rpm --showrc |grep Rich
> say:
>  rpmlib(RichDependencies) = 4.12.0-1
> 
> and redhat-rpm-config.fc28 requires
>  rpmlib(RichDependencies) <= 4.12.0-1
> 
> So redhat-rpm-config install fine because 4.12.0-1 == 4.12.0-1.
> But if ever we get some other weak dependency and rpm will start to provide:
>  rpmlib(RichDependencies) = 5.50.0-1
> 
> Then anything which requires
>  rpmlib(RichDependencies) <= 4.12.0-1
> will be installable.
> You can try it by bulding dummy rpm file with:
>  Provides: rpmlib(RichDependencies) = 5.50.0-1
> 
> So I really think that the condition should be "rpmlib(RichDependencies) >= 4.12.0-1"
> 

No. There is deliberately and explicitly no guarantee of forward compatibility in how rpm uses rpmlib() dependencies.

And -- as I said before -- rpmlib() dependencies and their versions are the wrong approach to what you are attempting.

>> And in fact the rich dependency tracking version is a fine example of how the version is not trustworthy: rich
>> dependencies got added in 4.13.0, not 4.12.0 as the rpmlib() dependency would have you think.
> 
> It seems [1] that Rpm does not check the version in rpmlib() string to anything related to version of rpm. For rpm it is
> just string. So rpm does not care which version it is 12 or 13 and dummy spec with:
>   Requires: rpmlib(RichDependencies) <= 4.12.0-1
> Is not installable on EL7 because of there is rpm-4.11.3, but because nothing provides there 'rpmlib(RichDependencies)'
> at all.
> 

Yes. That is exactly what is supposed to happen. The rpmlib() dependencies are satisfied by the rpm being used, not the package(s) being installed.

> In fact, I do not think that rpm should check rpm real version. These virtual provides are fine. Only that, Rpm should
> check the "rpmlib()" dependencies first and if they are satisfied (and only if) rpm should read and evaluate all other
> dependencies.

There is no additional benefit to checking rpmlib() dependencies first, or as part of normal dependency processing: in both cases you will get a failed operation.

> According my investigation DNF is unable to do that. The logic in DNF is in `dnf/rpm/transaction.py` where method
> addInstall from rpmlib is used to add package to transaction and then in test() is called `tserrors =
> self.ts.run(cb.callback, '')` which is just call to rpmlib.
> 

Yes. DNF must run with a version of rpm able to handle rich dependencies. That can be done by backporting, or by using a 2nd copy of rpm bindings/libraries.

In general, rpmlib() dependencies should not be attempted in user packaging because the dependencies are tracking features that are in use in the running version of rpm, not the packages in the transaction. And since some rpm is being used, the set of features is constant, and can only be changed by restarting DNF with a newer version of rpm, which is a different, and more complex, upgrade solution than other packages.

73 de Jeff
> 
> [1] I tried dummy spec with:
>  Requires: rpmlib(RichDependencies) <= 5.14.1-9
> on my F28 with rpm-4.14.1-9.fc28.x86_64 and it install like a charm.
> 
> Miroslav
> _______________________________________________
> Rpm-ecosystem mailing list
> Rpm-ecosystem at lists.rpm.org
> http://lists.rpm.org/mailman/listinfo/rpm-ecosystem