Bug 79184

Summary: Incorrect dependency computation when upgrading KDE packages
Product: [Retired] Red Hat Linux Reporter: Alexandre Oliva <aoliva>
Component: kdelibsAssignee: Ngo Than <than>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: jbj, mitr
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-12-22 12:43:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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