+++ This bug was initially created as a clone of Bug #201092 +++ Given a 4u3 system that has the setup from bz #200250: installed ------------- mozilla x86_64 mozilla-nspr i386, x86_64 mozilla-nss i386, x86_64 'up2date seamonkey' is run, and you get: installed ----------- mozilla-nspr i386 mozilla-nss i386 seamonkey x86_64 seamonkey-nspr i386, x86_64 seamonkey-nss i386, x86_64 This behavior in-and-of itself could be debated, but a more fundamental issue exists... if I, the user, now want the seamonkey-nss & seamonkey-nspr i386 versions, one path at least doesn't work: [root@dhcp59-210 ~]# up2date --arch=i386 seamonkey-nspr seamonkey-nss Fetching Obsoletes list for channel: rhel-x86_64-as-4... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- seamonkey-nspr 1.0.3 0.el4.1 i386 seamonkey-nspr 1.0.3 0.el4.1 x86_64 seamonkey-nss 1.0.3 0.el4.1 i386 seamonkey-nss 1.0.3 0.el4.1 x86_64 Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: package seamonkey-nspr-1.0.3-0.el4.1 is already installed package seamonkey-nss-1.0.3-0.el4.1 is already installed [root@dhcp59-210 ~]# up2date --arch=i386 seamonkey-nspr seamonkey-nss Fetching Obsoletes list for channel: rhel-x86_64-as-4... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- seamonkey-nspr 1.0.3 0.el4.1 i386 seamonkey-nspr 1.0.3 0.el4.1 x86_64 seamonkey-nss 1.0.3 0.el4.1 i386 seamonkey-nss 1.0.3 0.el4.1 x86_64 Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: package seamonkey-nspr-1.0.3-0.el4.1 is already installed package seamonkey-nss-1.0.3-0.el4.1 is already installed So, --arch doesn't work in this instance. It's important to note, this does *not* block the updating of other packages. Furthermore, running 'up2date -uf' *does* update the mozilla-[nspr|nss].i386 package to the seamonkey ones. If I had to guess, --arch probably only affects what the universe of outcome packages are. I suspect up2date, after it determines desired arch + version, does a check against installed packages using name-version-release-epoch *only*. It finds the x86_64 version already installed, so it thinks it has nothing to do, perhaps.
Needs to stay on the 3.9 blocker list. Pradeep has committed the fix for 4.5, and is working to porting the fix to 3.9. Reassigned bug to Pradeep.
User bnackash's account has been closed
*** Bug 240212 has been marked as a duplicate of this bug. ***
verified
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-2007-0439.html