Bug 201092 - up2date --arch doesn't adequately take into account obsoletes (or something)
up2date --arch doesn't adequately take into account obsoletes (or something)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Pradeep Kilambi
Corey Welton
:
: 231985 (view as bug list)
Depends On:
Blocks: 218647 240212
  Show dependency treegraph
 
Reported: 2006-08-02 15:17 EDT by Bret McMillan
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2007-0250
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-01 19:18:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bret McMillan 2006-08-02 15:17:14 EDT
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.
Comment 1 Pradeep Kilambi 2007-01-03 12:47:37 EST
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.
Comment 2 Pradeep Kilambi 2007-01-05 16:13:04 EST
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.
Comment 4 Peter Staubach 2007-03-08 15:13:33 EST
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.
Comment 5 Peter Staubach 2007-03-08 15:15:07 EST
Ignore previous, wrong BZ.  Sorry...
Comment 6 Corey Welton 2007-03-22 09:57:57 EDT
QA Verified -- new version works as described in comment #2
Comment 7 Corey Welton 2007-03-22 09:58:08 EDT
QA Verified -- new version works as described in comment #2
Comment 9 Red Hat Bugzilla 2007-05-01 19:18:14 EDT
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
Comment 10 Pradeep Kilambi 2007-05-22 18:14:41 EDT
*** Bug 231985 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.