Bug 139537 - RHEL4 - RHN update on x86_64 yields "package gcc-3.4.2-6.fc3 is already installed"
Summary: RHEL4 - RHN update on x86_64 yields "package gcc-3.4.2-6.fc3 is already insta...
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date   
(Show other bugs)
Version: 4.0
Hardware: x86_64 Linux
Target Milestone: ---
: ---
Assignee: Adrian Likins
QA Contact: Max Spevack
Depends On:
Blocks: 137160
TreeView+ depends on / blocked
Reported: 2004-11-16 16:39 UTC by James Laska
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-01 22:17:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
available updates (up2date -l) (12.81 KB, text/plain)
2004-11-16 16:39 UTC, James Laska
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2005:169 normal SHIPPED_LIVE up2date bug fix update 2005-04-01 05:00:00 UTC

Description James Laska 2004-11-16 16:39:01 UTC
I installed RHEL4-Beta2 onto an x86_64 which includes the following relevant


When attempt to update to the RHEL4-Beta2 RHN channel to pull down the attached
list of updates, I get the following error.

Testing package set / solving RPM inter-dependencies...
RPM package conflict error.  The message was:
Test install failed because of package conflicts:
package gcc-3.4.2-6.fc3 is already installed

If I manually remove libgnat-3.4.2-6.fc3.i386 I am able to bypass the error. 
However, this does not seem to be the expected behavior as the error does not
indicate that libgnat is to blame.  Futher inspection reveals this might be
multi-lib related as libgnat.i386 and gcc.x86_64 are interacting

Comment 1 James Laska 2004-11-16 16:39:01 UTC
Created attachment 106815 [details]
available updates (up2date -l)

Comment 2 Adrian Likins 2004-11-17 00:09:14 UTC
Try this with up2date-4.3.63, there have been some
multilib depsolve related bug fixes since 4.3.44

Comment 6 James Laska 2005-01-06 16:21:06 UTC
have not observed this on x86_64 ... this may mean fixed, or it may be that the
RHN channel content has changed since originally discovered.  I am going to
assume this is fixed and will reopen if the problem resurfaces.

Comment 9 Jay Turner 2005-02-08 15:21:21 UTC
I'm hoping this was just a side-effect of the inter-beta updates, but I'm moving
this to the U1 list to make sure it gets resolved before something bad happens.

Comment 10 Jay Turner 2005-02-15 14:24:09 UTC
Update here.  This is biting us with RHEL4-GA as well, so not just some
side-effect.  With up2date-4.4.5-1 and up2date-4.4.7-1, I'm getting the error
above.  Here's what doesn't make any sense:

1) up2date is stating that libgnat is obsoleted by gcc, but this is nonsensical,
as libgnat is multi-arch and gcc is native arch, so you can't obsolete across
architectures; up2date shouldn't even notice the obsolete
2) it appears that since up2date does notice this obsolete it decides to
"install"  gcc-3.4.3-9.EL4 in order to perform the obsolete; this is all well
and good except that gcc-3.4.3-9.EL4 is already installed and therefore should
never have made it into the transaction set

So, while Jakub failed to consider the multilib case when he added the
obsoletes, up2date shouldn't be acting as it is and should be following the RPM
conventions (which take into account architecture on obsoletes.)  This is the
reason that anaconda doesn't have a conniption.

This is going to hit any users that install the "Arch Compatibility" component
on x86_64, s390x or IA64, so probably need to get something fixed ASAP.

Comment 11 Adrian Likins 2005-02-15 17:09:32 UTC
re #10

1) why is #1 nonsensical? We've obsoleted across arches
before (gdb64 comes to mind). 

2) Not sure whats going on here... is gcc-3.4.3-9 supposed
to obsolete all *gnat* or just "older than 3.4.3-9" *gnat*?
To me the above spec file is just trying to make gcc-3.4.3-9
require matching version of *gnat*, and doing it with an obsolete
seems strange. 

Comment 12 Jakub Jelinek 2005-02-15 17:18:07 UTC
The obsoletes were added on architectures that used to support gnat/libgnat,
but in RHEL4 no longer do (x86_64, ia64, ppc) with the intent that installing
the new gcc package causes removal of {libgnat,gcc-gnat}-3.2.x etc.
Unfortunately, I did not think about multilib when adding that and e.g. up2date
on FC3 (with yum backed instead of RHN) certainly never complained to me.

GCC packages in U1 will surely have Ada reenabled on x86_64, ia64 and ppc
(as the bug that was preventing bootstrap has been finally fixed) and I have
already changed the <= to < in the Obsoletes in CVS.

But, as Jay told, if you install RHEL4 on say x86_64, up2date -u will not even
run, so the big question is if this can be somehow solved on the server side.
Because otherwise the only option I see is a text only errata that asks users to
rpm -e libgnat on {x86_64,ia64,s390x} if they are having problems up2date -u'ing.

Comment 13 Adrian Likins 2005-02-15 18:13:07 UTC
the "bug" seems to be that the "available" gcc obsoletes
libgnat <= 3.4.3-9.EL4, and gets added as a potential
to upgrade, without verifying that it's already the installed version.

It doesn't check because thats not supposed to be possible. Ie,
we have a package installed that obsoletes something, and we have
the package installed that it obsoletes. AFAIK, that was never
supported before (in fact, theres a fair amount of code in
up2date to make sure it doesn't happen, since at one point in
time, doing so caused rpm to crash in weird and 
interesting ways...).

In this case, it's a bit odd since the package that is being obsoleted
is i386, and the obsoleting package is x86_64, which up2date doesn't
take into account. Argubably it should, but that would break cases
we've had in the past where it was assumed it would obsolete across

As for a workaround, first thing that comes to mind is revving the
gcc packages. Albeit, not a pretty solution. I suspect the obsolete
on libgnat isnt needed at all, since there is no libgnat.x86_64 to
obsolete as best I can tell. (Was there on rhel3?)

Another possibility might be to introduce a new obsolete on libgnat
from a package that needs to be installed/updated. But I'm not
sure that would eliminate gcc being pulled in as a obsoleting package
for libgnat as well. 

Simply removing the bit of gcc obsoleting libgnat from the obsoletes
info should probably work, though I'm not sure if that would cause
other problems. If a system does have a libgnat installed (rhel3
upgrades?) it might leave unsolved deps.   

Comment 14 Adrian Likins 2005-02-16 00:15:06 UTC
up2date-4.4.8 building which should fix this, once deployed.

Not sure if we just want to push it out, or do some other
workaround in the meantime. 

Comment 16 Jay Turner 2005-02-16 10:38:29 UTC
Initial testing does point to 4.4.8-1 resolving this issue.

Comment 18 Max Spevack 2005-03-09 21:03:14 UTC
Testing the fix with up2date-

I installed a clean version of rhel-4 (RC iso) onto an x86_64 box.  I
then manually upgraded to up2date-, and ran up2date -uf.

up2date -uf ran cleanly, and successfully.


Comment 19 Jay Turner 2005-03-10 07:22:37 UTC
Hold up here a second.  Are we dropping the requirement that up2date update
itself first?  This was a sticking point the first time around, that releasing
the errata was still going to require a manual update from the customer which is
a pretty horrible user experience.

Putting in NEEDINFO to get a resolution to this issue.

Comment 20 Max Spevack 2005-03-10 15:24:31 UTC
Jay, there is an up2date- which needs to be tested.  In testing this, I
will ensure that starting with the base up2date that shipped with rhel-4, a user
can run up2date, pull down automatically the new up2date, and then continue the
upgrade process smoothly.

Comment 21 Max Spevack 2005-03-29 22:32:16 UTC
This bug has been tested with up2date- and it is PROD_READY.

Comment 22 Tim Powers 2005-04-01 22:17:30 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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