Bug 85856 - error in dependency logic of rpm
Summary: error in dependency logic of rpm
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 8.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-09 16:24 UTC by Gerald Teschl
Modified: 2007-04-18 16:51 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-03-17 17:40:51 UTC

Attachments (Terms of Use)

Description Gerald Teschl 2003-03-09 16:24:02 UTC
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

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

Comment 1 Jeff Johnson 2003-03-10 15:53:23 UTC
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.

Comment 2 Gerald Teschl 2003-03-10 20:35:02 UTC
Both packages have an EPOCH=1:

[root@soliton root]#rpm -qp --qf '%{EPOCH}:%{VERSION}-%{RELEASE}\n'
[root@soliton root]#rpm -qp --qf '%{EPOCH}:%{VERSION}-%{RELEASE}\n' gimp


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?

Comment 3 Jeff Johnson 2003-03-10 21:09:41 UTC
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!)
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

Comment 4 Gerald Teschl 2003-03-12 10:28:56 UTC
OK. I understand. But this implies that pretty much every rpm in the distro
is broken;-(

Comment 5 Gerald Teschl 2003-03-12 10:48:34 UTC
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?

Comment 6 Jeff Johnson 2003-03-12 14:28:24 UTC
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.

Comment 7 Peter Bowen 2003-03-17 14:35:29 UTC
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

Is there a suggestion for ISVs who need to require a certain upstream version
without caring about distributor epochs?

Comment 8 Jeff Johnson 2003-03-17 14:57:27 UTC
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.

Comment 9 Aleksey Nogin 2003-03-17 17:27:08 UTC
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"?

Comment 10 Jeff Johnson 2003-03-17 17:40:51 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.