Bug 139537

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