Bug 139345
| Summary: | 'up2date [package-name]' behavior is unpredictable on multilib | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | John Poelstra <poelstra> |
| Component: | up2date | Assignee: | Bryan Kearney <bkearney> |
| Status: | CLOSED NOTABUG | QA Contact: | Beth Nackashi <bnackash> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | abourne, benl |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | ia64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-12-08 18:32:31 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: | |||
| Bug Blocks: | 191074, 191079, 218648 | ||
Blocking rhnupr4u4 and rhnupr3u8 to track the progress of the release Moving bugs to the CanFix List 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...) 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 This bug did not make the code freeze. It will not be fixed in this releasee Reea ligning to the next one. /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. 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 Did you reproduce the issue raised in the first comment? That is not the expected behavior. (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. Re-closing this bug as per jbowes' last comment. |
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: