Bug 139537
Summary: | RHEL4 - RHN update on x86_64 yields "package gcc-3.4.2-6.fc3 is already installed" | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | James Laska <jlaska> | ||||
Component: | up2date | Assignee: | Adrian Likins <alikins> | ||||
Status: | CLOSED ERRATA | QA Contact: | Max Spevack <mspevack> | ||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 4.0 | CC: | benl, dff, jakub, jturner, mihai.ibanescu, mikem | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | x86_64 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-04-01 22:17:29 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 137160 | ||||||
Attachments: |
|
Description
James Laska
2004-11-16 16:39:01 UTC
Created attachment 106815 [details]
available updates (up2date -l)
Try this with up2date-4.3.63, there have been some multilib depsolve related bug fixes since 4.3.44 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. 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. 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. 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. 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. 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 arch. 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. up2date-4.4.8 building which should fix this, once deployed. (dist-4E-errata-candidate) Not sure if we just want to push it out, or do some other workaround in the meantime. Initial testing does point to 4.4.8-1 resolving this issue. Testing the fix with up2date-4.4.5.1-4 I installed a clean version of rhel-4 (RC iso) onto an x86_64 box. I then manually upgraded to up2date-4.4.5.1-4, and ran up2date -uf. up2date -uf ran cleanly, and successfully. PROD_READY 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. Jay, there is an up2date-4.4.5.2 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. This bug has been tested with up2date-4.4.5.3 and it is PROD_READY. 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. http://rhn.redhat.com/errata/RHBA-2005-169.html |