Hide Forgot
rpm lists failed dependencies in situations where there are no failed dependencies. For example: Take an 8.0 suystem. Downgrade to the gimp version from 7.3. [root@soliton root]# rpm -q gimp gimp-devel rpm gimp-1.2.3-4 gimp-devel-1.2.3-9 rpm-4.1-9 Then try to upgrade gimp [root@soliton root]# rpm -U gimp-1.2.3-9.i386.rpm error: Failed dependencies: gimp = 1.2.3 is needed by (installed) gimp-devel-1.2.3-9 This makes no sense (at least to me) since "gimp = 1.2.3" is provided by gimp-1.2.3-9.
Check for an Epoch:. If there is an Epoch: used in gimp packages, then the Requires: needs to be written as Requires: gimp = N:1.2.3 rather than RequiresL gimp = 1.2.3 (Note: substitute "N" as appropriate) Otherwise, a missing Epoch: for an installed package is treated as Epoch: 0 and the error reported is, indeed, correct.
Both packages have an EPOCH=1: [root@soliton root]#rpm -qp --qf '%{EPOCH}:%{VERSION}-%{RELEASE}\n' gimp-1.2.3-4.i386.rpm 1:1.2.3-4 [root@soliton root]#rpm -qp --qf '%{EPOCH}:%{VERSION}-%{RELEASE}\n' gimp 1:1.2.3-9 Moreover, 1) why does rpm tell me that it cannot upgrade the package due to missing dependencies, but once I've installed it using --nodeps it no longer complains about missing deps (rpm -V) 2) if I downgrade both gimp and gimp-devel I can upgrade both at the same time, but if I first upgrade gimp-devel and then gimp it does not work?
Yup. Welcome to the concept of epoch promotion! A missing Epoch: is ignored when part of a transaction, but treated as Epoch: 0 after install, leading to different behavior depending on whether the package is installed (or not). See other candidate head scratchers by running "rpm -Vav --nofiles". Each one of those complaints is from a mis-written (and broken!) dependency. i In each and every case the right thing to do is to explicitly supply an epoch in the dependency as in Requires: name = epoch:version-release
OK. I understand. But this implies that pretty much every rpm in the distro is broken;-(
I tought about this problem a bit an I feel that the current behaviour is bad for the following reason: Suppose there is a package foo which requires at least version 1.1 of bar. Redhat ships version 1:1.1 of bar and then decides to downgrade to 2:1.0. According to what you suggest I should put requires >= 1:1.1 into foo. Hence, for rpm, the requirement will be satisfied by 2:1.0, but foo will not work since it requires version 1.1 of bar! In summary, "requires 1.1" should imply "require version 1.1 of the software" and "requires 0:1.1" should imply require version 0:1.1 of the package. That is, the epoch should be ignored if it is not part of the requirement. Do I miss something?
You miss the fact that Epoch: is the most significant part of version comparison. If missing, comparison result is undefined. The only logical definition (imho) is to treat a missing Epoch: as Epoch: 0. And no, not every package, nor even a majority of packages, are broken. Furthermore, in every case, the fix is trivial. Specify what Epoch: is intended.
How are ISVs supposed to deal with this? Currently it is possible to create a single package that works on a variety of distros, generally put putting all your files in /opt. However, with this change, it just effectively became impossible. Is there a suggestion for ISVs who need to require a certain upstream version without caring about distributor epochs?
ISV's should fix their packages, or report bugs against distro packages that have unspecified but essential values. rpm is free to choose essential but missing/unspecified values any way at all. That includes coin flips ;-). I have no idea how/why files in /opt is pertinent to EVR comparison. The current behavior is reasonable, since, indeed, packages mentioned on the command line are usually newer than already installed packages.
IMHO a very important question was asked here and never answered - if package X needs version >=a.b of package Y, but would be satisfied with any epoch of Y, how can that be specified? It is important to provide such a mechanism because as comment #7 correctly points out, 3-rd party packagers often would not care what the epochs are that are used by a particular distribution, the only thing they would care about is the "upstream" version of the installed package! I believe that the "summary" suggestion in comment #5 is very reasonable. The comment #6 objections are IMHO irrelevant: > You miss the fact that Epoch: is the most significant > part of version comparison. Significant for whom? For the RPM program? Then it's an RPM misfeature and this bug asks for it to be fixed. For the packager? But the whole point is that some packages do not care (and have no reason to care!) about epoch! > Furthermore, in every case, the fix is trivial. Specify what > Epoch: is intended. How can I specify: "I do not care about epoch, I only care about the upstream version of the package"?
If you use an Epoch:, then all dependencies must be forevermore written with an explicit epoch, as in Requires: foo = E:V There is no way to "ignore" Epoch, it's the most significant part of rpmvercmp, so some value *nust* be assumed if no value is specified, or dependency comparison is unspecified. The only thing that makes sense is to assume Epoch: 0 when no value is specified. That is what is implemented in rpm-4.1 and later, albeit with the one remaining wart that Epoch: is ignored for added packages from the CLI. If you don't like this behavior, then you need to hold the conversation on <rpmlist@redhat.com>, not here in bugzilla, as this is not a bug and the behavior is not going to change.