Bug 201092
| Summary: | up2date --arch doesn't adequately take into account obsoletes (or something) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Bret McMillan <bretm> |
| Component: | up2date | Assignee: | Pradeep Kilambi <pkilambi> |
| Status: | CLOSED ERRATA | QA Contact: | Corey Welton <cwelton> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 4.0 | CC: | a.gormanly |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | RHBA-2007-0250 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-05-01 23:18:13 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: | 218647, 240212 | ||
|
Description
Bret McMillan
2006-08-02 19:17:14 UTC
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.
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. 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. Ignore previous, wrong BZ. Sorry... QA Verified -- new version works as described in comment #2 QA Verified -- new version works as described in comment #2 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 *** Bug 231985 has been marked as a duplicate of this bug. *** |