Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 79184 - Incorrect dependency computation when upgrading KDE packages
Incorrect dependency computation when upgrading KDE packages
Product: Red Hat Linux
Classification: Retired
Component: kdelibs (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ngo Than
Depends On:
  Show dependency treegraph
Reported: 2002-12-06 16:27 EST by Alexandre Oliva
Modified: 2008-05-01 11:38 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-22 07:43:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2002-12-06 16:27:17 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
rpm incorrectly complains that kdelibs-devel depends on kdelibs, even though
kdelibs is being upgraded to a compatible version.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Take a 8.0 box with all errata released prior to the KDE erratum released this
week.  Also update all packages other than those listed in step 2.

2.Check the remaining updates that have dependencies on others, so they can't be
installed one by one, and try to install them in a single RPM command.  The
updates remaining to be installed are:
upgrading to kpf-3.0.3-3.2 from 3.0.3-3...
upgrading to kppp-3.0.3-3.2 from 3.0.3-3...
upgrading to ksirc-3.0.3-3.2 from 3.0.3-3...
upgrading to ktalkd-3.0.3-3.2 from 3.0.3-3...
upgrading to kxmlrpcd-3.0.3-3.2 from 3.0.3-3...
upgrading to lisa-3.0.3-3.2 from 3.0.3-3...
upgrading to kmail-3.0.3-3.2 from 3.0.3-3...
upgrading to knewsticker-3.0.3-3.2 from 3.0.3-3...
upgrading to knode-3.0.3-3.2 from 3.0.3-3...
upgrading to korn-3.0.3-3.2 from 3.0.3-3...
upgrading to kdenetwork-devel-3.0.3-3.2 from 3.0.3-3...
upgrading to kdenetwork-libs-3.0.3-3.2 from 3.0.3-3...
upgrading to kdict-3.0.3-3.2 from 3.0.3-3...
upgrading to kit-3.0.3-3.2 from 3.0.3-3...
upgrading to kdelibs-3.0.3-8.3 from 3.0.3-8...
upgrading to libkscan-3.0.3-5 from 3.0.3-3...
upgrading to libkscan-devel-3.0.3-5 from 3.0.3-3...
upgrading to kooka-3.0.3-5 from 3.0.3-3...
upgrading to kdebase-3.0.3-14 from 3.0.3-13...
upgrading to kdebase-devel-3.0.3-14 from 3.0.3-13...

Note that kdelibs-devel has already been updated to 3.0.3-8.3, since it doesn't
depend on kdelibs-3.0.3-8.3.

Actual Results:  RPM refuses to install all these packages at once, with the
following message:
error: Failed dependencies:
        kdelibs = 3.0.3 is needed by (installed) kdelibs-devel-3.0.3-8.3
error installing /n/redhat/updates/8.0/en/os/i386/kpf-3.0.3-3.2.i386.rpm

Expected Results:  It should not have complained.  It also complains if I
attempt to update only kdelibs, after kdelibs-devel has been updated.

Additional info:

If I downgrade kdelibs-devel to 3.0.3-8, and then add
kdelibs-devel-3.0.3-8.3.i386.rpm to the single RPM command, it works.
Comment 1 Jeff Johnson 2002-12-07 14:24:18 EST
Packaging problem, kdelibs-devel Requires: needs an explicit

bash$ rpm -qp --requires kdelibs-devel-3.0.3-8.3.i386.rpm 
qt-devel >= 3.0.5
kdelibs = 3.0.3

Note: As written, this is the same as
	Requires: kdelibs = 0:3.0.3
but needs to be
	Requires: kdelibs = 6:3.0.3

bash$ rpm -qp --provides kdelibs-3.0.3-8.3.i386.rpm
kdelibs = 6:3.0.3-8.3

Comment 2 Alexandre Oliva 2002-12-07 15:28:53 EST
Well, then...  The rpm bug is that it does *NOT* complain about the unsatisfied
0:3.0.3 dependency when I upgrade both kdelibs and kdelibs-devel at the same
time, right?
Comment 3 Jeff Johnson 2002-12-07 16:05:51 EST
rpm doesn't complain about a lot of things that it should.

FWIW, try rpm -Vav to see all the busted dependencies
like kdelibs-devel.

And, for extra credit, add (undocumented) --promoteepoch
to the set of packages above. The issue is how a non-specified
Epoch: should be treated, either in the same Epoch: (behavior
with --promoteepoch), or as equivalent to Epoch: 0.

I choose to treat a missing Epoch: as Epoch: 0, as that
makes sense. Too bad that breaks some packaging, there's
been a policy in place since Red Hat 6.2 to always specify
the Epoch: in a Requires: if the corresponding Provides:
has an Epoch:
Comment 4 Jeff Johnson 2002-12-07 16:08:24 EST
And, yes, added packages are Epoch: promoted (i.e.
missing Epoch: disables Epoch: comparison), while the
same package, after being installed, is treated as Epoch: 0.
Comment 5 Ngo Than 2002-12-08 13:48:25 EST
i wonder why this issue was not found by QA?

ok, anaway i'm waiting for next security fix in next days, so i will do a new
kde errata.
Comment 6 Ngo Than 2002-12-22 07:43:00 EST
it's fixed in 3.0.5a-1, which will be released as errata soon

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