Red Hat Bugzilla – Bug 230153
Dependency behavior when depending on unversioned provides feels wrong
Last modified: 2007-11-16 20:14:55 EST
Description of problem:
When you add a requirement to a specific version of a resource and a package is
providing that resource without versioning information the requirement is
treated as fulfilled.
Version-Release number of selected component (if applicable):
Create an RPM that requires perl(DBI) >= 1.43 and try to install it
Steps to Reproduce:
1. create a RPM that requires perl(DBI) >= 1.43
2. install the rpm
3. notice that the installation doesn't fail, although there is no perl(DBI) >= 1.43
The package is installed and the actual code fails
The package shouldn't be installable
What I have:
$ rpm -q --provides perl-DBI | grep 'perl(DBI)'
$ rpm -qp --requires /home/arogge/rpm/RPMS/i386/test-1.0.0-1.noarch.rpm
perl(DBI) >= 1.43
$ rpm -i --test /home/arogge/rpm/RPMS/i386/test-1.0.0-1.noarch.rpm
actually I think this test-package should not be installable, because nothing on
my system actually provides perl(DBI) >= 1.43 - there's only something providing
perl(DBI). So the package is actually installable, but the dependency I actually
wanted is not fulfilled.
I know that simply changing this would render many packages uninstallable.
However, these packages are currently broken anyway, because their dependencies
are only fulfilled by accident (i.e. the version of the package installed is
acidentially recent enough so the code doesn't break).
This issue is probably reproducible on other RHEL releases and probably also on
Fedora. However, I didn't try it.
Yes. Provides without an explicit version are interpreted as providing "all versions" and
so match your requires.
Changing to a closed range like
Provides: perl(DBI) <= 1.50
(I've chosed "1.50" as an arbitrary example) is the best fix.
Otherwise express your requirement differently (if possible).
As explained above by Jeff, this is intentional rpm behavior wrt unversioned
provides and not a bug.
Yeah. That's correct.
I looked around a bit and the bug is actually in perl.prov. perl.prov is often
unable to extract the version numbers from perl modules and thus you end up with
a bunch of perl-rpms with unversioned provides.
Yup, see bug #249135.