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.
2 questions: 1. what does yum list updates alsa\* return? 2. if you run yum update alsa-lib.i386 what happens?
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.
how did the alsa-lib.x86_64 package get installed in the first place?
tested kdelibs x86_64 and i386 too. updated separately. No problems.
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.
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.
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! ;)
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.
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
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!
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.
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.
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".
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
> 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.
Can you paste the bottom (the section right before the user confirmation onward) of the 2.1.13 output?
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
Attaching a patch. Apply it to 2.1.13 depsolve.py Run yum update dbus again I think it should fix it.
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.
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.
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.
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.
okay. closing this as fixed now. I really think that'll do it.