On Tue, 18 Oct 2005, Dave Lowell wrote:
Hi there, I package a lot of our internal software into RPMs. I am careful to make sure new software releases correctly capture inter-package dependencies to enforce correct software installs. So I was quite surprised this week to witness a case in which RPM allowed a package to be installed, even though its dependencies were not satisfied. The operator who conducted the RPM upgrade in question did not use any special command line options to defeat dependence checks. Here is the output from the session in which this incorrect RPM upgrade took place.
<snip>
As you can see, the 'modules' RPM version 1.22.1 depends on the 'server' RPM having version 2.6.1 or greater. But installed on the box is 'server' RPM 2.4.1. Nevertheless, the upgrade to 'modules' 1.22.1 succeeds, although it should have failed. Can anyone think of a reason the dependence check failed to fail?
There's epoch of 1 in the server package, causing it to be considered newer than *any version* without an epoch. Change the modules dependency to "Requires: server >= 1:2.6.1" to take the epoch into account.
The other possible cause, like others mentioned, is having a package with "Provides: server" in the system (possibly the old server package)
- Panu - _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
