Bug 139345 - 'up2date [package-name]' behavior is unpredictable on multilib
'up2date [package-name]' behavior is unpredictable on multilib
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.0
ia64 Linux
medium Severity medium
: ---
: ---
Assigned To: Bryan Kearney
Beth Nackashi
: Reopened
Depends On:
Blocks: 191074 191079 218648
  Show dependency treegraph
 
Reported: 2004-11-15 09:21 EST by John Poelstra
Modified: 2013-01-10 03:47 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-08 13:32:31 EST
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 John Poelstra 2004-11-15 09:21:51 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
While working on an Errata for the guile package I noticed that on the
ia64 arch up2date does not download the i386 package. This is
inconsistent with the s390x and x86_64 platforms where up2date
download s both the native package and the multilib package (e.g.
s390x AND s390;  x86_64 AND i386).

See example following with ia64 and s390x.

~~~~~~~~~
ON IA64
~~~~~~~~
.qa.[root@test151 2004:539]# up2date --download --src guile-devel

Fetching Obsoletes list for channel: rhel-ia64-as-3...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------
guile-devel                             1.6.4          8.30.1        
   ia64


Testing package set / solving RPM inter-dependencies...
########################################
guile-devel-1.6.4-8.30.1.ia ########################## Done.
guile-1.6.4-8.30.1.src.rpm: ########################## Done.
guile-1.6.4-8.30.1.ia64.rpm ########################## Done.
guile-1.6.4-8.30.1.src.rpm: ########################## Done.
The following packages were added to your selection to satisfy
dependencies:

Name                                    Version        Release
--------------------------------------------------------------
guile                                   1.6.4          8.30.1

~~~~~~~~~~~
s390x
~~~~~~~~~~~
.qa.[root@kryten 2004:539]# up2date --download --src guile-devel

Fetching Obsoletes list for channel: rhel-s390x-as-3...

Fetching rpm headers...
########################################

Name                                    Version        Rel
----------------------------------------------------------
guile-devel                             1.6.4          8.30.1        
   s390x


Testing package set / solving RPM inter-dependencies...
########################################
guile-devel-1.6.4-8.30.1.s3 ########################## Done.
guile-1.6.4-8.30.1.src.rpm: ########################## Done.
guile-1.6.4-8.30.1.s390.rpm ########################## Done.
guile-1.6.4-8.30.1.src.rpm: ########################## Done.
guile-1.6.4-8.30.1.s390x.rp ########################## Done.
guile-1.6.4-8.30.1.src.rpm: ########################## Done.
The following packages were added to your selection to satisfy
dependencies:

Name                                    Version        Release
--------------------------------------------------------------
guile                                   1.6.4          8.30.1
guile                                   1.6.4          8.30.1 

Version-Release number of selected component (if applicable):
up2date-4.2.38-1.ia64

How reproducible:
Always

Steps to Reproduce:
1. Uninstall ALL guile-* packages
2. Remove all guile-* RPMs from /var/spool/up2date
3. up2date --download --src guile-devel
    

Actual Results:  On ia64 the i386 package is not downloaded

Expected Results:  On ia64 the i386 package should be downloaded

Additional info:
Comment 3 Fanny Augustin 2006-04-10 20:30:57 EDT
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release
Comment 4 Fanny Augustin 2006-04-13 15:33:41 EDT
Moving bugs to the CanFix List
Comment 5 Bret McMillan 2006-04-25 15:27:50 EDT
This is probably an ia64 arch scoring issue... see bz # 168250 ...

Do you have a machine still exhibiting this behavior I could look at (sorry, I
know this is a really old bug...)
Comment 6 Fanny Augustin 2006-05-08 15:12:29 EDT
This bug did not make the code freeze and it will not be fiixed during this
release cycle.  Re-aligning bug to the next release
Comment 7 Fanny Augustin 2006-05-08 16:05:34 EDT
This bug did not make the code freeze.  It will not be fixed in this releasee 
Reea ligning to the next one.
Comment 15 Bret McMillan 2006-08-09 14:20:39 EDT
/me changes the version to RHEL4, we'll close NOTABUG if it's not an issue there.

As part of the RHEL 4.5 release, we're going to need a page that describes what
rules exactly are followed when you perform the command "up2date package-name".

We have a host of design questions, and probable bugs that need to get resolved
at the same time to ensure this makes any sort of sense across the board.

Right now, the 10k-ft view from where I sit is:
1) if a pkg isn't installed yet, 'up2date [package-name]' figures out the "best"
arch and goes with it, resolving deps minimally.
2) if a pkg-name is installed, 'up2date [package-name]' will seek to install
highest vre's for all installed arches (so long as the newly-available packages
are viewed as currently compatible with system... could be an odd case w/ ia64 &
software emulation?)
3) we need to review from a design point how obsoletes factors into 'up2date
[package-name]' vs 'up2date -u', and ensure the code fits desired behavior.
Comment 16 James Bowes 2006-11-07 09:18:50 EST
I was able to get my hands on a variety of multilib machines and try this out on
rhel 4 u4 yesterday.

All arches that I tested behaved in the same manner. They would only download
the minimal set of rpms required to get what was requested, and for the best
arch. I was then able to use '--arch=' to specify i386 for example and get the
other arch version of the package.

AFAIK, this is the behaviour that we expect, so closing as NOTABUG
Comment 17 John Poelstra 2006-11-07 12:47:51 EST
Did you reproduce the issue raised in the first comment?  That is not the
expected behavior.
Comment 18 James Bowes 2006-11-07 13:01:05 EST
(In reply to comment #17)
> Did you reproduce the issue raised in the first comment?  That is not the
> expected behavior.

All arches acted in the same fasion. They only grabbed the packages for the
primary arch. This is the behaviour Bret describes in comment #15 point 1.
Comment 19 Bret McMillan 2006-12-08 13:32:31 EST
Re-closing this bug as per jbowes' last comment.

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