> On Jun 26, 2018, at 7:15 AM, Miroslav Suchý <msu...@redhat.com> wrote: > > Dne 26.6.2018 v 12:17 Neal Gompa napsal(a): >> rpmlib() dependencies are virtual, they aren't provided by anything, >> but are processed during the transaction and verified. > > 1) So the number in rpmlib(RichDependencies) means what version of rpm I > should have. Right? > > 2) The version of rpm I need to parse this RPM is in dependency list, which I > cannot parse on EL7 because there is too > old rpm. So I have chicken and egg problem. Any idea how to solve this? >
The rpmlib() tracking dependency isn't what is needed or useful to supply a better error message. The core problem is that the depsolver used by mock must be using bindings/libraries that implement rich dependencies, as well as metadata parsers that can represent rich dependencies. An improved error message needs to come from the depsolver, not mock, perhaps through a feature vector which mock might retrieve. Suggesting a version of rpm by examining rpmlib() Provides: only deals the bottom of a rather complex depsolver software stack that is surely going to evolve while being deployed on EL7. That software stack involves many versions, not just the rpm version, nor the rpmlib() tracking dependency version. Having 2 versions of RPM on EL7 is one too many, and the long EL7 lifetime requirements inhibiting back ports of features are going to be very painful when some critical package chooses to use rich dependencies. I hope there is an adequate plan in place for deploying rich dependencies. 73 de Jeff > Miroslav > _______________________________________________ > Rpm-ecosystem mailing list > Rpm-ecosystem@lists.rpm.org > http://lists.rpm.org/mailman/listinfo/rpm-ecosystem _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
