Bug 144376 - yum's dependency resolution may pick old to-be-updated packages.
yum's dependency resolution may pick old to-be-updated packages.
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
3
All Linux
medium Severity high
: ---
: ---
Assigned To: Jeremy Katz
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-01-06 12:10 EST by Axel Thimm
Modified: 2014-01-21 17:50 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-02-03 13:56:22 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)
This should apply to depsolve.py in 2.1.13 (with a little fuzz, maybe) (1.84 KB, patch)
2005-02-03 03:22 EST, Seth Vidal
no flags Details | Diff

  None (edit)
Description Axel Thimm 2005-01-06 12:10:00 EST
Description of problem:

A multilib system with alsa-lib of different versions for alsa-lib
fails to update it.

# rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' alsa-lib
alsa-lib-1.0.7-17.rhfc3.at.x86_64
alsa-lib-1.0.6-5.i386
# yum update alsa-lib
Setting up Update Process
Setting up Repo:  atrpms
repomd.xml                100% |=========================|  951 B   
00:00     
Setting up Repo:  base
repomd.xml                100% |=========================| 1.1 kB   
00:00     
Setting up Repo:  updates-released
repomd.xml                100% |=========================|  951 B   
00:00     
Reading repository metadata in from local files
atrpms    : ################################################## 801/801
base      : ################################################## 2852/2852
updates-re: ################################################## 474/474
Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package alsa-lib.i386 0:1.0.7-17.rhfc3.at set to be updated
--> Running transaction check
--> Processing Dependency: libasound.so.2(ALSA_0.9) for package: esound
--> Processing Dependency: libasound.so.2 for package: SDL_image
--> Processing Dependency: libasound.so.2 for package: kdemultimedia
--> Processing Dependency: libasound.so.2(ALSA_0.9.5) for package:
alsa-lib
--> Processing Dependency: libasound.so.2(ALSA_0.9) for package: kdelibs
--> Processing Dependency: libasound.so.2(ALSA_0.9.0rc4) for package:
kdemultimedia
--> Processing Dependency: libasound.so.2 for package: alsa-lib
--> Processing Dependency: libasound.so.2(ALSA_0.9.0rc4) for package:
esound
--> Processing Dependency: libasound.so.2 for package: arts
--> Processing Dependency: libasound.so.2 for package: esound
--> Processing Dependency: libasound.so.2(ALSA_0.9.0rc8) for package:
alsa-lib
--> Processing Dependency: libasound.so.2 for package: kdelibs
--> Processing Dependency: libasound.so.2 for package: SDL_mixer
--> Processing Dependency: libasound.so.2(ALSA_0.9) for package: alsa-lib
--> Processing Dependency: libasound.so.2 for package: SDL
--> Processing Dependency: libasound.so.2(ALSA_0.9) for package:
kdemultimedia
--> Processing Dependency: libasound.so.2(ALSA_0.9) for package: arts
--> Processing Dependency: libasound.so.2 for package: kdebase
--> Processing Dependency: libasound.so.2(ALSA_0.9) for package: SDL
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package alsa-lib.i386 0:1.0.6-3 set to be updated
--> Running transaction check

Dependencies Resolved
Transaction Listing:
  Update: alsa-lib.i386 0:1.0.7-17.rhfc3.at

Performing the following to resolve dependencies:
  Update: alsa-lib.i386 0:1.0.6-3
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Finished Transaction Test
Transaction Check Error:   package alsa-lib-1.0.7-17.rhfc3.at (which
is newer than alsa-lib-1.0.6-3) is already installed
  package alsa-lib-1.0.6-5 (which is newer than alsa-lib-1.0.6-3) is
already installed


Version-Release number of selected component (if applicable):
yum 2.1.12

How reproducible:
always

Steps to Reproduce:
1. Install FC3/x86_64
2. Install different versions of alsa-lib for i386 and x86_64
3. Try to update alsa-lib (for instance from ATrpms)
  
Actual results:
See above

Expected results:
The i386 package should have been updated

Additional info:
rpm -Uhv does the right thing, so there are no Conflicts/Obsoletes etc.

This may be perhaps another incarnation of bug #140832 (see also
https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=379 and
http://bugzilla.atrpms.net/show_bug.cgi?id=289), but the yum version
used is considered to have fixed this.
Comment 1 Seth Vidal 2005-01-06 13:33:50 EST
2 questions:
1. what does yum list updates alsa\* return?
2. if you run yum update alsa-lib.i386 what happens?

Comment 2 Seth Vidal 2005-01-06 15:11:36 EST
I don't have alsa-lib to test with but I did the test on fc3 + updates
with cups-libs.

I updated cups-libs.x86_64 using yum:
yum update cups-libs.x86_64

it completed fine.

then I ran: yum update cups-libs

it found the remaining cups-libs.i386 update and applied it.

this might be alsa-lib specific.
I'll try with some more multilib packages.
Comment 3 Seth Vidal 2005-01-06 15:16:51 EST
how did the alsa-lib.x86_64 package get installed in the first place?
Comment 4 Seth Vidal 2005-01-06 15:27:15 EST
tested kdelibs x86_64 and i386 too.

updated separately.

No problems. 
Comment 5 Axel Thimm 2005-01-06 15:50:28 EST
In reply to comment #2
> I don't have alsa-lib to test with but I did the test on fc3 +
> updates with cups-libs.

alsa-lib-1.0.6-3 and alsa-lib-1.0.6-5 are part of fc3 + updates.

Anyway, I found the bug, and it's not a multilib one, but probably a
duplicate of bug #140832 (so I fixed the summary). Since #140832 is
resolved as fixed, I wouldn't yet assign this as a duplicate (or it
will get forgotten).

The alsa-lib.i386 that is to be upgraded has split off the %{_libdir}
parts into libasound2. When yum sees that it will update alsa-lib to a
package that does not anymore provide libasound.so.2, it searches the
list of packages to resolve this with and finds the old alsa-lib
package. This results in yum wanting to update

alsa-lib-1.0.6-5.i386

with

alsa-lib-1.0.7-17.rhfc3.at.i386 _AND_
alsa-lib-1.0.6-3.i386

(see comment #0).

The correct behaviour would be to exclude packages during dependency
resolution where a newer package exists in the rpm database, or are to
be updated during the same transaction, or are Conflicted/Obsoleted by
the target rpm set.

Then yum would have found the libasound2-1.0.7-17.rhfc3.at.i386
instead of the not-to-be-used-anymore alsa-lib-1.0.6-3.i386.

This applies to any package that will split off some required
dependencies into another package.
Comment 6 Seth Vidal 2005-01-06 15:52:13 EST
okay - I think this has been fixed in cvs already but I'll have to
check. I know I threw in some checks to rule it out.

Comment 7 Axel Thimm 2005-01-07 13:05:28 EST
This one breaks more than just alsa-lib@ATrpms. glib2, flac, rpm
itself and more are affected, as ATrpms is splitting packages finer
than Red Hat (in order to provide cross-repo and also future
compatibility packages).

People on fedora-list are already tearing ATrpms apart because yum
does not work with it. Help! ;)
Comment 8 Axel Thimm 2005-01-18 09:07:38 EST
A recent exhibition of this bug is the current wireless-tools vs
NetworkManager/kdenetwork bug in FC3's updates.

wireless-tools does not provide anymore libiw.so.27 as required by
NetworkManager/kdenetwork, so yum's upgrade algorithm decides to
(re)install both new and old wireless-tools:

Resolving Dependencies
--> Populating transaction set with selected packages. Please wait.
---> Package wireless-tools.i386 1:28-0.pre4.1.fc3 set to be updated
--> Running transaction check
--> Processing Dependency: libiw.so.27 for package: NetworkManager
--> Processing Dependency: libiw.so.27 for package: kdenetwork
--> Restarting Dependency Resolution with new changes.
--> Populating transaction set with selected packages. Please wait.
---> Package wireless-tools.i386 1:27-0.pre25.2 set to be updated
--> Running transaction check

Dependencies Resolved
Transaction Listing:
  Update: wireless-tools.i386 1:28-0.pre4.1.fc3

Performing the following to resolve dependencies:
  Update: wireless-tools.i386 1:27-0.pre25.2

The primary bug is in the repo, but still yum should not allow for
installation of both versions.
Comment 9 Seth Vidal 2005-01-19 02:16:04 EST
Nope, wasn't fixed in cvs from before, but now it is :)

If you could  - please check out yum from yum's cvs and run:
PYTHONPATH=./ ./yummain.py whatevercommand-you-saw-that-caused-it


I think it's resolved now, I did a bunch of testing and I believe it does the
right thing
Comment 10 Axel Thimm 2005-01-19 19:46:55 EST
Looks very good now (and there seems to be an impressive speed-up compared to
2.1.12). Also the wireless-tools/NetworkManager bug is not killing yum anymore.

There are some other bugs (like b-2 obsoleting a-1, and a-3 obsoleting b-2
confusing yum, as well as yum not wanting to upgrade my rpm & librpm rpms), but
they are not of the nature of this ticket. I'll try to narrow these cases
further and open new reports.

So the concluding question is: When will this code be released? :)

Thanks!
Comment 11 Axel Thimm 2005-01-28 08:34:05 EST
I have uploaded CVS cuts from yum to

http://atrpms.net/name/yum-bleeding/

It does solve a lots of cases, but there seem to be some open still.
Anyone watching this bug may consider testing these rpms (in
at-bleeding repos) and report here on on yum's own bugzilla.
Comment 12 Michal Jaegermann 2005-02-03 01:44:42 EST
Is this the same problem?  It is not clear to me.

With the latest security updates to dbus running yum-2.1.12-0.fc3
with -d5 prints the following:

Building updates object
Resolving Dependencies
1107410749.88
--> Populating transaction set with selected packages. Please wait.
Adding Package dbus-glib - 0.22-10.FC3.2.i386 in mode u
---> Package dbus-glib.i386 0:0.22-10.FC3.2 set to be updated
Adding Package dbus-devel - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-devel.x86_64 0:0.22-10.FC3.2 set to be updated
Adding Package dbus - 0.22-10.FC3.2.i386 in mode u
---> Package dbus.i386 0:0.22-10.FC3.2 set to be updated
Adding Package dbus-python - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-python.x86_64 0:0.22-10.FC3.2 set to be updated
Adding Package dbus-x11 - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-x11.x86_64 0:0.22-10.FC3.2 set to be updated
Adding Package dbus - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus.x86_64 0:0.22-10.FC3.2 set to be updated
--> Running transaction check
# of Deps = 1
dbus-glib requires: dbus = 0.22-10
--> Processing Dependency: dbus = 0.22-10 for package: dbus-glib
Multiple Packages match. dbus-glib-0.22-10
   dbus-glib - 0.22-10.x86_64
   dbus-glib - 0.22-10.i386
Resolving for installed requiring package: dbus-glib - 0.22-10.x86_64
Resolving for requirement: dbus = 0.22-10
Mode for pkg providing dbus = 0.22-10: u
Cannot find an update path for dep for: dbus = 0.22-10
Searching pkgSack for dep: dbus
Potential match for dbus from dbus - 0.22-10.i386
Matched dbus - 0.22-10.i386 to require for dbus
Potential match for dbus from dbus - 0.22-10.x86_64
Matched dbus - 0.22-10.x86_64 to require for dbus
Potential match for dbus from dbus - 0.22-10.FC3.2.i386
Potential match for dbus from dbus - 0.22-10.FC3.2.x86_64
dbus - 0.22-10.i386 is in providing packages but it is already
installed, removing.
dbus - 0.22-10.x86_64 is in providing packages but it is already
installed, removing.
miss = 1
conf = 0
CheckDeps = 0
--> Finished Dependency Resolution
Dependency Process ending
Error: missing dep: dbus = 0.22-10 for pkg dbus-glib

OK, so now lets try each architecture separately:

Resolving Dependencies
1107411031.0
--> Populating transaction set with selected packages. Please wait.
Adding Package dbus - 0.22-10.FC3.2.i386 in mode u
---> Package dbus.i386 0:0.22-10.FC3.2 set to be updated
Adding Package dbus-glib - 0.22-10.FC3.2.i386 in mode u
---> Package dbus-glib.i386 0:0.22-10.FC3.2 set to be updated
--> Running transaction check

Dependencies Resolved
1107411031.07
Transaction Listing:
  Update: dbus.i386 0:0.22-10.FC3.2
  Update: dbus-glib.i386 0:0.22-10.FC3.2
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Adding Package dbus - 0.22-10.FC3.2.i386 in mode u
Adding Package dbus-glib - 0.22-10.FC3.2.i386 in mode u
Finished Transaction Test
Transaction Check Error:   file /etc/dbus-1/session.conf from install
of dbus-0.22-10.FC3.2 conflicts with file from package dbus-0.22-10


Does not work.  And with x86_64 first:

Resolving Dependencies
1107411066.79
--> Populating transaction set with selected packages. Please wait.
Adding Package dbus-python - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-python.x86_64 0:0.22-10.FC3.2 set to be updated
Adding Package dbus-x11 - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-x11.x86_64 0:0.22-10.FC3.2 set to be updated
Adding Package dbus - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus.x86_64 0:0.22-10.FC3.2 set to be updated
Adding Package dbus-devel - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-devel.x86_64 0:0.22-10.FC3.2 set to be updated
--> Running transaction check

Dependencies Resolved
1107411066.86
Transaction Listing:
  Update: dbus.x86_64 0:0.22-10.FC3.2
  Update: dbus-devel.x86_64 0:0.22-10.FC3.2
  Update: dbus-python.x86_64 0:0.22-10.FC3.2
  Update: dbus-x11.x86_64 0:0.22-10.FC3.2
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Test
Adding Package dbus-python - 0.22-10.FC3.2.x86_64 in mode u
Adding Package dbus-x11 - 0.22-10.FC3.2.x86_64 in mode u
Adding Package dbus - 0.22-10.FC3.2.x86_64 in mode u
Adding Package dbus-devel - 0.22-10.FC3.2.x86_64 in mode u
Finished Transaction Test
Transaction Check Error:   file /etc/dbus-1/session.conf from install
of dbus-0.22-10.FC3.2 conflicts with file from package dbus-0.22-10

And now we are stuck.

Only after
rpm -Uvh --nodeps dbus-0.22-10.i386.rpm dbus-0.22-10.x86_64.rpm
I could do "yum update 'dbus*'" and then it works.

Comment 13 Michal Jaegermann 2005-02-03 02:01:33 EST
Oops, a command to "untangle" things from the previous comment should,
of course, be:

rpm -Uvh --nodeps dbus-0.22-10.FC3.2.i386.rpm \
         dbus-0.22-10.FC3.2.x86_64.rpm

Wrong "cut-and-waste".
Comment 14 Seth Vidal 2005-02-03 02:04:33 EST
You're not running 2.1.13 so I can't really tell if this is a new
problem or not.

Update to yum 2.1.13 from updates-testing then retest that.

Thanks
Comment 15 Michal Jaegermann 2005-02-03 02:19:08 EST
> Update to yum 2.1.13 from updates-testing then retest that.

I upgraded to yum 2.1.13 and forced reinstallation of all previous
dbus packages.  An attempt to do updates via yum unfortunately
ended up exactly in the same way as in comment #12.
Comment 16 Seth Vidal 2005-02-03 02:22:27 EST
Can you paste the bottom (the section right before the user
confirmation onward) of the 2.1.13 output?
Comment 17 Michal Jaegermann 2005-02-03 02:26:45 EST
Hopefuly that is what you want to see.  This is with -d5 again:

--> Populating transaction set with selected packages. Please wait.
Member: dbus-devel.x86_64 0-0.22-10.FC3.2 - u
Adding Package dbus-devel - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-devel.x86_64 0:0.22-10.FC3.2 set to be updated
Member: dbus.i386 0-0.22-10.FC3.2 - u
Adding Package dbus - 0.22-10.FC3.2.i386 in mode u
---> Package dbus.i386 0:0.22-10.FC3.2 set to be updated
Member: dbus.x86_64 0-0.22-10.FC3.2 - u
Adding Package dbus - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus.x86_64 0:0.22-10.FC3.2 set to be updated
Member: dbus-glib.i386 0-0.22-10.FC3.2 - u
Adding Package dbus-glib - 0.22-10.FC3.2.i386 in mode u
---> Package dbus-glib.i386 0:0.22-10.FC3.2 set to be updated
Member: dbus-x11.x86_64 0-0.22-10.FC3.2 - u
Adding Package dbus-x11 - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-x11.x86_64 0:0.22-10.FC3.2 set to be updated
Member: dbus-python.x86_64 0-0.22-10.FC3.2 - u
Adding Package dbus-python - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-python.x86_64 0:0.22-10.FC3.2 set to be updated
--> Running transaction check
# of Deps = 1

Dep Number: 1/1
dbus-glib requires: dbus = 0.22-10
--> Processing Dependency: dbus = 0.22-10 for package: dbus-glib
Multiple Packages match. dbus-glib-0.22-10
   dbus-glib - 0.22-10.x86_64
   dbus-glib - 0.22-10.i386
Resolving for installed requiring package: dbus-glib - 0.22-10.x86_64
Resolving for requirement: dbus = 0.22-10
Mode for pkg providing dbus = 0.22-10: u
Cannot find an update path for dep for: dbus = 0.22-10
Searching pkgSack for dep: dbus
Potential match for dbus from dbus - 0.22-10.i386
Matched dbus - 0.22-10.i386 to require for dbus
Potential match for dbus from dbus - 0.22-10.x86_64
Matched dbus - 0.22-10.x86_64 to require for dbus
Potential match for dbus from dbus - 0.22-10.FC3.2.i386
Potential match for dbus from dbus - 0.22-10.FC3.2.x86_64
dbus - 0.22-10.i386 is in providing packages but it is already
installed, removing.
dbus - 0.22-10.x86_64 is in providing packages but it is already
installed, removing.
miss = 1
conf = 0
CheckDeps = 0
--> Finished Dependency Resolution
Dependency Process ending
Error: Missing Dependency: dbus = 0.22-10 is needed by package dbus-glib
Comment 18 Seth Vidal 2005-02-03 03:20:31 EST
Attaching a patch. Apply it to 2.1.13 depsolve.py
Run yum update dbus again

I think it should fix it.

Comment 19 Seth Vidal 2005-02-03 03:22:09 EST
Created attachment 110583 [details]
This should apply to depsolve.py in 2.1.13 (with a little fuzz, maybe)

Apply to depsolve.py on 2.1.13 - might have a little fuzz.
Then retest yum update dbus.

Jeremy, might want to hold 2.1.13 in updates-testing and either let this come
out with 2.1.14 or apply it to 2.1.13 before it goes out to updates-released.
Comment 20 Michal Jaegermann 2005-02-03 11:11:38 EST
I applied a patch from comment #19 to 2.1.13 from updates-testing
(offset -12 lines) and renamed, for a good measure,
/usr/lib/python2.3/site-packages/yum/depsolve.pyc to get it out
of way, and I still have the same results as before.  Bummer!

I fail to seen any changes in a debugging output after this patch
was applied.
Comment 21 Michal Jaegermann 2005-02-03 11:23:21 EST
I think that we are hitting some dependency trouble.  Not reall sure
where.  Here is a fragment of debugging output (with the patch
already applied):

Adding Package dbus-python - 0.22-10.FC3.2.x86_64 in mode u
---> Package dbus-python.x86_64 0:0.22-10.FC3.2 set to be updated
--> Running transaction check
# of Deps = 1

>>>> mj - so far so good

Dep Number: 1/1
dbus-glib requires: dbus = 0.22-10

>>>> mj - and here we are already in trouble as we really want
>>>> mj - 0.22-10.FC3.2 for dbus-glib and not 0.22-10

--> Processing Dependency: dbus = 0.22-10 for package: dbus-glib
Calling rpmdb.returnHeaderByTuple on dbus-glib.x86_64 0:0.22-10
Calling rpmdb.returnHeaderByTuple on dbus-glib.i386 0:0.22-10
Multiple Packages match. dbus-glib-0.22-10
   dbus-glib - 0.22-10.x86_64
   dbus-glib - 0.22-10.i386 already in ts u, skipping

>>>> mj - correct but not what is needed.
Comment 22 Michal Jaegermann 2005-02-03 13:25:21 EST
Ugh! False alarm.  Sorry about that!

I was doing updates from a local repository, which gets its content
via some scripts from mirrors, and until I started to comb through
all possibilities I failed to notice that unexplicably 
dbus-glib-0.22-10.FC3.2.x86_64.rpm is missing.  Once I corrected
that everything resolved and updated.  I do not think that even
yum update to a test version was required.
Comment 23 Seth Vidal 2005-02-03 13:56:22 EST
okay. closing this as fixed now.

I really think that'll do it.

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