Bug 461110

The patch attached to this bug has absolutely nothing to do with the release noted problem that you are referencing above and will not, in any way, solve the above issue.

Patch is still very busted.

First off, you missed the point I was making about i386 entirely.  Install openmpi 1.2.3.i386, then install your openmpi x86_64 then look at the alternatives on the system and you'll see that it's created alternative links for a non-existent 1.2.3.x86_64 to remove and they obviously never will get removed.  This is because the test $1 -gt 1 will be true even if you aren't upgrading whenever you have an i386 package already installed (like I mentioned before, this is the crux of bug 460878 and your patch is *still* vulnerable to it).

However, and more importantly, I have no idea why you are trying to change i386 links in the x86_64 rpm.  You should never touch the i386 links in the x86_64 rpm.  And on top of that, this patch is written to assume x86_64 only.  If you run this rpm through the same i386 tests, it will fail miserably.

So, you would need to switch the scripts to not do anything with any arch other than the arch it was compiled on, so use of the %{_arch} macro will be necessary.  Additionally, it needs to find the right files depending on arch so you can't hard code things like mpilibs64 = /usr/lib64/openmpi/... you would instead have to do things the way it was done originally, mpilibs%{mode} = %{_libdir}/openmpi/... (you can't use %{mpidir} since that's the current directory).  You also can't rely on the $1 -gt 1 thing to truly tell you if you are upgrading, so you can't create links unless you *know* that they will get removed, and that means instead of blindly creating the links, you need to check if the link target is present and then create the link.  The nice part about that is it's safe to recreate an existing link, so you don't even need to check if it's broken, you just need to create the right link to match any targets that exist.

A simpler, more effective, and more correct patch might look like this:

if [ -f %{_libdir}/openmpi/1.2.3-gcc/openmpi.ld.conf ]; then
        /usr/sbin/alternatives --install /etc/ld.so.conf/mpi%{mode}.conf \
                mpilibs%{mode} %{_libdir}/openmpi/1.2.3-gcc/openmpi.ld.conf
elif [ -f %{_libdir}/openmpi/openmpi.ld.conf ]; then
        # We have an openmpi-1.1.1 package from prior to the changes that
        # allow multiple openmpi packages to be present installed
        /usr/sbin/alternatives --install /etc/ld.so.conf/mpi.conf \
                mpilibs %{_libdir}/openmpi/openmpi.ld.conf
fi

This method assumes two things.  That if a file from a specific package exists, then that package is currently installed (doesn't mean we are upgrading though, we could be just installing, but in that case we'll be installed next to the other package) and that even if we aren't upgrading at the moment the other package will eventually clean up these links.  The same basic thing can be done in the base openmpi package but is even simpler since we only ever had onr link we used there.  And likewise for the devel package but it will be more complex like the libs because the devel link target changed over time.

The whole issue of 1.1.1-8 not removing links properly has to be handled too, but you can't mess with devel package links in the lib package scripts.  Each package can *only* deal with its own links.  In order to handle the 1.1.1-8 not removing links properly, it will require that this rpm have a Conflicts: openmpi <= 1.1.1-8 in order to force the package to be removed when this is installed (otherwise, it would be possible to have 1.1.1-8 installed, and then install this, so you would need to leave the links for the non-upgrade case, then then when you rpm -e openmpi-1.1.1-8 later, it wouldn't remove its own links and you'd have dangling crap, so the conflicts allows us to know for sure that openmpi-1.1.1-8 will be gone when we are done here, so we can remove its links).

However, this is still one upgrade path you haven't been testing.  I'm not entirely sure why you've been building this as an openmpi-1.2.5-5 rpm because you already *know* I can't rebuild a new 1.2.5-5 rpm, this has to be 1.2.5-6 or later *and* it has to work when upgrading the real 1.2.5-5 rpm in those places that have already just bit the bullet and did the upgrade as the release notes talked about.

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

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 therefore 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/RHEA-2009-1023.html