Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 79184 - Incorrect dependency computation when upgrading KDE packages
Summary: Incorrect dependency computation when upgrading KDE packages
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kdelibs
Version: 8.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Ngo Than
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-12-06 21:27 UTC by Alexandre Oliva
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2002-12-22 12:43:00 UTC

Attachments (Terms of Use)

Description Alexandre Oliva 2002-12-06 21:27:17 UTC
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 19:24:18 UTC
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 20:28:53 UTC
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 21:05:51 UTC
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 21:08:24 UTC
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 18:48:25 UTC
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 12:43:00 UTC
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.