Bug 133156
| Summary: | up2date fails on dependencies when i386 and x86-64 both exist | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Erich Hoover <ehoover> |
| Component: | up2date | Assignee: | Bret McMillan <bretm> |
| Status: | CLOSED CANTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | CC: | aleksey, mattdm, oliva |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-10-29 15:04:01 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: | 130887 | ||
|
Description
Erich Hoover
2004-09-21 22:54:48 UTC
what commandline useage was given? Not sure what you mean by "(this is example is with trying to install the update to i386 firefox only)" does that imply useage of "--arch i386" ? Command-line: "up2date --nosig -u firefox" What I meant was that instead of attempting all the updates that I'd just selected the i386 firefox update - from this command line I would actually have expected the x86-64 firefox to install as well but it only added the i386 one to the package list. What appears to happen is that up2date sees that no i386 package for things exists (like ORBit2-2.11.2-1 in the example) and adds both the i386 and the x86-64 package even though the x86-64 package is already installed. At the moment you can work around this by manually downloading each of the updates from a mirror and installing them, but I think that up2date should be smart enough to only add the package for the architecture that it needs it for. I had up2date dependancy problems after installing FC3T2 over an FC2T1 installation. Apparently, this left duplicate versions of packages in the rpm database. One example was the evolution package. When I tried to up2date it, there were conflicts with the 1.5.3-1 version. rpm -q evolution showed I had both the 1.5.3-1 and 1.5.94.1-1 version installed. I erased the 1.5.3-1, then ran the up2date again and it was successful. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [root@localhost ~]# up2date --nosig -u evolution http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide using mirror: http://mirror.hiwaay.net/redhat/fedora/linux/core/development/x86_64/ Fetching Obsoletes list for channel: fedora-core-rawhide... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- evolution 2.0.1 2 x86_64 Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- evolution-data-server 1.0.1 1 evolution-devel 2.0.1 2 gnutls 1.0.20 3 libgal2 2.2.2 1 mozilla-nspr 1.7.3 5 mozilla-nss 1.7.3 5 libgal2-devel 2.2.2 1 file /usr/bin/evolution from install of evolution-2.0.1-2 conflicts with file from package evolution-1.5.3-1 [root@localhost ~]# rpm -q evolution evolution-1.5.3-1 evolution-1.5.94.1-1 [root@localhost ~]# rpm -e evolution-1.5.3-1 [root@localhost ~]# rpm -q evolution evolution-1.5.94.1-1 [root@localhost ~]# up2date --nosig -u evolution http://fedora.redhat.com/download/up2date-mirrors/fedora-core-rawhide using mirror: http://mirror.hiwaay.net/redhat/fedora/linux/core/development/x86_64/ Fetching Obsoletes list for channel: fedora-core-rawhide... Fetching rpm headers... ######################################## Name Version Rel ---------------------------------------------------------- evolution 2.0.1 2 x86_64 Testing package set / solving RPM inter-dependencies... ######################################## evolution-2.0.1-2.x86_64.rp ########################## Done. evolution-data-server-1.0.1 ########################## Done. evolution-devel-2.0.1-2.x86 ########################## Done. gnutls-1.0.20-3.x86_64.rpm: ########################## Done. libgal2-2.2.2-1.x86_64.rpm: ########################## Done. mozilla-nspr-1.7.3-5.x86_64 ########################## Done. mozilla-nss-1.7.3-5.x86_64. ########################## Done. libgal2-devel-2.2.2-1.x86_6 ########################## Done. Preparing ########################################### [100%] Installing... 1:mozilla-nspr ########################################### [100%] 2:libgal2 ########################################### [100%] 3:mozilla-nss ########################################### [100%] 4:libgal2-devel ########################################### [100%] 5:gnutls ########################################### [100%] 6:evolution-data-server ########################################### [100%] 7:evolution ########################################### [100%] 8:evolution-devel ########################################### [100%] The following packages were added to your selection to satisfy dependencies: Name Version Release -------------------------------------------------------------- evolution-data-server 1.0.1 1 evolution-devel 2.0.1 2 gnutls 1.0.20 3 libgal2 2.2.2 1 mozilla-nspr 1.7.3 5 mozilla-nss 1.7.3 5 libgal2-devel 2.2.2 1 [root@localhost ~]# rpm -q evolution evolution-2.0.1-2 The original problem is still present in FC3-rc1. The worst part of it is that it doesn't say which package brought the unwanted dependency in, so you have to guess to find it out. As far as I could tell from some experiments, it's handling dependencies on package names and/or on i386 libraries as uncolored, and then bringing in both 32- and 64-bit versions of the packages that provide them. I.e., if you up2date -i foo and foo is available as both x86_64 and i386, it selects only x86_64, but if foo has a dep on bar, or libbar.so.0, and bar is available in both i386 and x86_64, up2date will attempt to install both variants of bar, and if the x86_64 version is already installed, it fails as above. To make matters worse, --arch isn't documented in the man-page, so I had no clue to try that. reproduced this with aoliva's approach and think I have a fix, but i'm not sure yet if the fix breaks anything else ;-> testing atm... fix seems to work in my testing up2date-4.3.47-3 has it Cool, much better now! I've given it a try after a fresh install, and I still can't just install my meta-package that brings in all of the add-ons I like to have installed on my boxes, but now I only have to install one or two packages by hand. The two problems that remain are related with some package that presumably has xmms as a dep, and so it tries to install the i386 xmms (as well as the x86_64 xmms, that's already installed), and that fails because the x86_64 xmms is already installed, and there are some packaging conflicts. If I install ogle and mplayer early, and then my meta-package, it all goes well and nothing brings in xmms for i386. Very odd. So it looks like the problem is partially, but not completely solved. The other problem is that up2date keeps trying to reinstall gcc after I install my meta-package, that brings in, among other packages, distcc and ccache. distcc requires gcc34, which gcc provides. The odd thing is that, if I reinstall gcc (rpm -U --replacepkgs gcc), up2date will no longer attempt to reinstall gcc and fail because it's already installed. >The other problem is that up2date keeps trying to reinstall gcc after
>I install my meta-package, that brings in, among other packages,
>distcc and ccache. distcc requires gcc34, which gcc provides. The
>odd thing is that, if I reinstall gcc (rpm -U --replacepkgs gcc),
>up2date will no longer attempt to reinstall gcc and fail because it's
>already installed.
hmmm, that almost sounds like it could be an rpm database issue.
Can you try duplicating that after a `rpm --rebuilddb` ?
I need a fix for this today if it's going to get into FC3. Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! Closing per lack of response to previous comment. If this still occurs on FC3 or FC4 and is a security issue, please assign to Fedora Legacy and the appropriate version. The bug could also be filed against RHEL if it is relevant there. up2date has been replaced by pirut and pup in FC5 and FC6, the still fully supported versions of Fedora Core, so this bug will not be fixed unless it is a security issue. |