Bug 218647 - up2date --arch doesn't adequately take into account obsoletes (or something)
Summary: up2date --arch doesn't adequately take into account obsoletes (or something)
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date   
(Show other bugs)
Version: 3.0
Hardware: All Linux
medium
medium
Target Milestone: ---
Assignee: Pradeep Kilambi
QA Contact: Brandon Perkins
URL:
Whiteboard:
Keywords:
: 240212 (view as bug list)
Depends On: 201092
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-12-06 16:41 UTC by Pradeep Kilambi
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

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: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0439 normal SHIPPED_LIVE up2date bug fix update 2007-06-07 20:33:23 UTC

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@redhat.com'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



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