I installed RHEL4-Beta2 onto an x86_64 which includes the following relevant packages: libgnat-3.4.2-6.fc3.i386. gcc-3.4.2-6.fc3.x86_64. up2date-4.3.44-2.x86_64. 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
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