Bug 133156

Summary: up2date fails on dependencies when i386 and x86-64 both exist
Product: [Fedora] Fedora Reporter: Erich Hoover <ehoover>
Component: up2dateAssignee: Bret McMillan <bretm>
Status: CLOSED CANTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: 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 10:04:01 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 130887    

Description Erich Hoover 2004-09-21 18:54:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7)
Gecko/20040904 Firefox/0.9.3

Description of problem:
up2date has difficulty dealing with dependencies between i386 and
x86-64, it tries to add packages that it needs and then says they are
already installed.

Version-Release number of selected component (if applicable):
up2date-4.3.38-1.1

How reproducible:
Always

Steps to Reproduce:
1. Install latest updates yesterday (the 20th)
2. Try to install latest updates (presumably will update to FC3T2)


Actual Results:  (this is example is with trying to install the update
to i386 firefox only)
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
--------------------------------------------------------------
GConf2                                  2.7.92         1
GConf2                                  2.7.92         1
ORBit2                                  2.11.2         1
ORBit2                                  2.11.2         1
alsa-lib                                1.0.6          1
alsa-lib                                1.0.6          1
audiofile                               0.2.6          1
audiofile                               0.2.6          1
bzip2-libs                              1.0.2          13
bzip2-libs                              1.0.2          13
esound                                  0.2.35         2
esound                                  0.2.35         2
gamin                                   0.0.9          1
gnome-vfs2                              2.8.0          3
gnome-vfs2                              2.8.0          3
howl-libs                               0.9.6          3
howl-libs                               0.9.6          3
libbonobo                               2.6.2          2
libbonobo                               2.6.2          2
libgnome                                2.7.92         1
libgnome                                2.7.92         1
libxml2                                 2.6.13         1
gnome-vfs2-devel                        2.8.0          3
gnome-vfs2-smb                          2.8.0          3

package ORBit2-2.11.2-1 is already installed
package GConf2-2.7.92-1 is already installed
package libbonobo-2.6.2-2 is already installed
package audiofile-0.2.6-1 is already installed
package bzip2-libs-1.0.2-13 is already installed
package alsa-lib-1.0.6-1 is already installed
package esound-0.2.35-2 is already installed
package libgnome-2.7.92-1 is already installed


Expected Results:  Picks the appropriate architecture of the packages
it needs to add and installs them.

Additional info:
Comment 1 Adrian Likins 2004-09-23 18:16:06 EDT
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" ?
Comment 2 Erich Hoover 2004-09-23 18:24:24 EDT
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.
Comment 3 Joe Cox 2004-09-30 11:17:22 EDT
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
Comment 4 Alexandre Oliva 2004-10-25 03:53:11 EDT
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.
Comment 6 Adrian Likins 2004-10-26 18:29:21 EDT
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...
Comment 7 Adrian Likins 2004-10-27 11:47:25 EDT
fix seems to work in my testing
up2date-4.3.47-3 has it
Comment 8 Alexandre Oliva 2004-10-28 13:19:56 EDT
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.
Comment 10 Adrian Likins 2004-10-29 14:13:16 EDT
>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` ?
Comment 11 Elliot Lee 2004-11-01 11:13:10 EST
I need a fix for this today if it's going to get into FC3.
Comment 12 Matthew Miller 2006-07-10 16:36:59 EDT
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!
Comment 13 John Thacker 2006-10-29 10:04:01 EST
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.