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.
I dont think thats what is happening here. If it thinks it has nothing to do, then it should not even enter the transactionset. Basically its scheduling the transaction as asked, but while the depSolver checks for conflicts, it thinks that this package is already existant. Below is the case i tried: 1. ran $up2date seamonkey Installing... 1:seamonkey-nspr ########################################### [100%] 2:seamonkey-nss ########################################### [100%] 3:seamonkey ########################################### [100%] The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- seamonkey-nspr 1.0.5 0.1.el4 seamonkey-nss 1.0.5 0.1.el4 2. then $rpm -q --queryformat='%{n}-%{v}-%{r}-%{ARCH}\n' seamonkey-nss seamonkey-nspr seamonkey-nss-1.0.5-0.1.el4-i386 seamonkey-nss-1.0.5-0.1.el4-x86_64 seamonkey-nspr-1.0.5-0.1.el4-i386 seamonkey-nspr-1.0.5-0.1.el4-x86_64 we already have i386 and x86_64 (same as your case). now we try to re install wi th --arch, 3. then $up2date --arch=i386 seamonkey-nss seamonkey-nspr Name Version Rel ---------------------------------------------------------- seamonkey-nspr 1.0.5 0.1.el4 i386 seamonkey-nss 1.0.5 0.1.el4 i386 RPM package conflict error. The message was: Test install failed because of package conflicts: package seamonkey-nspr-1.0.5-0.1.el4 is already installed package seamonkey-nss-1.0.5-0.1.el4 is already installed I think the question here is why is it even adding it to transaction set when its already installed as per #2.
there are multiple issues related to --arch: 1. the above case mentioned, basically when arch is force we add the packages to available list with it checking if its already installed hence when we run $up2date --arch=i386 seamonkey-nss seamonkey-nspr it gives a conflict error as its already installed, but is still added to transaction set. Basically added a fileter to filter out the already installed pakcgaes from adding to updates by comparing the nvrea with the fix we get: $ [root@test07-64 ~]# up2date --arch=i386 seamonkey-nss seamonkey-nspr ###by passed action packages#### Fetching Obsoletes list for channel: rhel-x86_64-as-4... Fetching Obsoletes list for channel: rhn-tools-rhel-4-as-x86_64... Fetching rpm headers... ######################################## package to INSTALL [] Name Version Rel ---------------------------------------------------------- The following packages you requested are already updated: seamonkey-nss seamonkey-nspr [root@test07-64 ~]# 2. for example on an x86_64 box if i try: $ up2date --arch=i386 emacs we get The following packages you requested are already updated: emacs which is wrong, as $ rpm -q emacs package emacs is not installed instead up2date should say package is not found as only x86_64 version of package is available. this is because it checks for the available updates only by name rather than check even for arch when --arch is specified, now with the fix, we should see: $up2date --arch=i386 emacs Fetching Obsoletes list for channel: rhel-x86_64-as-4... Fetching Obsoletes list for channel: rhn-tools-rhel-4-as-x86_64... Fetching rpm headers... ######################################## package to INSTALL [] Name Version Rel ---------------------------------------------------------- The following packages you requested were not found: emacs as expected. if you give 2 archs on command line, for ex: $up2date --arch=i386 --arch=ia64 seamonkey-nss seamonkey-nspr it gives The following packages you requested were not found: seamonkey-nss seamonkey-nspr this is ok though vague. basically if user asks to install both arches of that package and we dont find one, we say not found. although it would be nice to say which arch is missing, but for now this should work as this is an unusual case.
In this case, there is an i386 version of firefox available. (I believe.) While RHN is busy saying that a new version of firefox is available, firefox-1.5.0.10, both "up2date -u firefox" and "up2date -u --arch=i386 firefox" say that all packages are up to date even though firefox-1.5.0.9 is the installed version.
Ignore previous, wrong BZ. Sorry...
QA Verified -- new version works as described in comment #2
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-0250.html
*** Bug 231985 has been marked as a duplicate of this bug. ***