Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 3 product line. The current stable release is 3.9. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 218647

Summary:	up2date --arch doesn't adequately take into account obsoletes (or something)
Product:	Red Hat Enterprise Linux 3	Reporter:	Pradeep Kilambi <pkilambi>
Component:	up2date	Assignee:	Pradeep Kilambi <pkilambi>
Status:	CLOSED ERRATA	QA Contact:	Brandon Perkins <bperkins>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	CC:	tsanders
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	RHBA-2007-0439	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-06-11 18:47:02 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	201092
Bug Blocks:

Description Pradeep Kilambi 2006-12-06 16:41:31 UTC

+++ 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.

Comment 2 Todd Sanders 2007-03-21 12:43:17 UTC

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.

Comment 3 Red Hat Bugzilla 2007-04-12 01:57:39 UTC

User bnackash's account has been closed

Comment 5 Pradeep Kilambi 2007-05-17 18:32:26 UTC

*** Bug 240212 has been marked as a duplicate of this bug. ***

Comment 6 wes hayutin 2007-05-21 18:50:44 UTC

verified

Comment 8 Red Hat Bugzilla 2007-06-11 18:47:02 UTC

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