Hide Forgot
Description of problem: Updating package fails. Fedora repo version is -0.9.7, updates version is -1.0.0 Version-Release number of selected component (if applicable): -1.0.0 How reproducible: Every time. Steps to Reproduce: 1. Remove fedora-updates.repo from /etc/yum.repos.d 2. Yum install libvpx: Setting up Install Process Package libvpx-0.9.7.1-1.fc16.x86_64 already installed and latest version Nothing to do (In this case, libvpx was already previously installed) 3. Result in /usr/lib64 ls -al libvpx* lrwxrwxrwx 1 root root 15 Feb 2 19:15 libvpx.so.0 -> libvpx.so.0.9.7 lrwxrwxrwx 1 root root 15 Feb 2 19:15 libvpx.so.0.9 -> libvpx.so.0.9.7 -rwxr-xr-x 1 root root 450488 Aug 16 15:31 libvpx.so.0.9.7 This is as expected: 4, Add fedora-updates.repo to /etc/yum.repos.d 5. Expected result something like: ls -al libvpx* lrwxrwxrwx 1 root root 15 Feb 2 19:15 libvpx.so.0 -> libvpx.so.1.0.0 lrwxrwxrwx 1 root root 15 Feb 2 19:15 libvpx.so.0.9 -> libvpx.so.1.0.0 -rwxr-xr-x 1 root root 15 Feb 2 19.15 libvpx.so.0.9.7 -> libvpx.so.1.0.0 -rwxr-xr-x 1 root root 471832 Feb 2 19:15 libvpx.so.1.0.0 Actual results: Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package libvpx.x86_64 0:0.9.7.1-1.fc16 will be updated --> Processing Dependency: libvpx.so.0()(64bit) for package: libavcodec52-0.7.10-50.fc16.x86_64 --> Processing Dependency: libvpx.so.0()(64bit) for package: 4:mplayer-1.0-88_snap20120102.fc16.x86_64 --> Processing Dependency: libvpx.so.0()(64bit) for package: libavcodec53-0.9-52.fc16.x86_64 ---> Package libvpx.x86_64 0:1.0.0-1.fc16 will be an update --> Finished Dependency Resolution Error: Package: 4:mplayer-1.0-88_snap20120102.fc16.x86_64 (@atrpms) Requires: libvpx.so.0()(64bit) Removing: libvpx-0.9.7.1-1.fc16.x86_64 (@fedora) libvpx.so.0()(64bit) Updated By: libvpx-1.0.0-1.fc16.x86_64 (updates) Not found Error: Package: libavcodec52-0.7.10-50.fc16.x86_64 (@atrpms) Requires: libvpx.so.0()(64bit) Removing: libvpx-0.9.7.1-1.fc16.x86_64 (@fedora) libvpx.so.0()(64bit) Updated By: libvpx-1.0.0-1.fc16.x86_64 (updates) Not found Error: Package: libavcodec53-0.9-52.fc16.x86_64 (@atrpms) Requires: libvpx.so.0()(64bit) Removing: libvpx-0.9.7.1-1.fc16.x86_64 (@fedora) libvpx.so.0()(64bit) Updated By: libvpx-1.0.0-1.fc16.x86_64 (updates) Not found You could try using --skip-broken to work around the problem ** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows: libvpx-1.0.0-1.fc16.x86_64 is a duplicate with libvpx-0.9.7.1-1.fc16.x86_64 I played with the SPEC file, to remove/replace symlinks, and installed the resulting binary rpm. I amended libvpx.spec at about line 116 to read as follows (and NO, I did not know what I was really doing!): %if %{generic_target} install -p libvpx.so.%{soversion} %{buildroot}%{_libdir} pushd %{buildroot}%{_libdir} rm -f libvpx.so rm -f libvpx.so.0 rm -f libvpx.so.0.9 rm -f libvpx.so.0.9.7 ln -sf libvpx.so.%{soversion} libvpx.so ln -sf libvpx.so.%{soversion} libvpx.so.0 ln -sf libvpx.so.%{soversion} libvpx.so.0.9 ln -sf libvpx.so.%{soversion} libvpx.so.0.9.7 popd %endif RPM update gives: root@tor1 x86_64]# rpm -Uvh libvpx-1.0.0-1.fc16.x86_64.rpm error: Failed dependencies: libvpx.so.0()(64bit) is needed by (installed) mplayer-4:1.0-88_snap20120102.fc16.x86_64 libvpx.so.0()(64bit) is needed by (installed) libavcodec53-0.9-52.fc16.x86_64 libvpx.so.0()(64bit) is needed by (installed) libavcodec52-0.7.10-50.fc16.x86_64 rpm -ivh --force installed the package and I ended up with a not-at-all-as expected: [root@tor1 lib64]# ls -al libvpx* lrwxrwxrwx 1 root root 15 Feb 2 19:15 libvpx.so.0 -> libvpx.so.0.9.7 lrwxrwxrwx 1 root root 15 Feb 2 19:15 libvpx.so.0.9 -> libvpx.so.0.9.7 -rwxr-xr-x 1 root root 450488 Aug 16 15:31 libvpx.so.0.9.7 lrwxrwxrwx 1 root root 15 Feb 3 11:47 libvpx.so.1 -> libvpx.so.1.0.0 lrwxrwxrwx 1 root root 15 Feb 3 11:47 libvpx.so.1.0 -> libvpx.so.1.0.0 -rwxr-xr-x 1 root root 471832 Feb 3 11:47 libvpx.so.1.0.0 RPM now reports: [root@tor1 ~]# rpm -qa libvpx libvpx-1.0.0-1.fc16.x86_64 libvpx-0.9.7.1-1.fc16.x86_64 So something is wrong in either the SPEC file, or in the 'make install' template such that {soversion} or {version} are misconstrued. I played with the SPEC file to no avail. Note yum check says they are duplicates, when the files clearly differ: from which I deduce that it is the versioning in the file which is wrong. Although this is on x86_64, I would assume it affectes ALL archs, and all linux-like OS which use make or make-like equivalents. Probably affects F15, rawhide, and RHEL(/Centos). Expected results: Additional info:
Confirming that it affects i686 as well.
There are so many issues with this bug report, but I will attempt to address the most obvious ones. #1. The upgrade failed, but not because of any problem with the libvpx package. If you look at your yum output, the reason is clear: Error: Package: 4:mplayer-1.0-88_snap20120102.fc16.x86_64 (@atrpms) Requires: libvpx.so.0()(64bit) Removing: libvpx-0.9.7.1-1.fc16.x86_64 (@fedora) libvpx.so.0()(64bit) Updated By: libvpx-1.0.0-1.fc16.x86_64 (updates) Not found Error: Package: libavcodec52-0.7.10-50.fc16.x86_64 (@atrpms) Requires: libvpx.so.0()(64bit) Removing: libvpx-0.9.7.1-1.fc16.x86_64 (@fedora) libvpx.so.0()(64bit) Updated By: libvpx-1.0.0-1.fc16.x86_64 (updates) Not found Error: Package: libavcodec53-0.9-52.fc16.x86_64 (@atrpms) Requires: libvpx.so.0()(64bit) Removing: libvpx-0.9.7.1-1.fc16.x86_64 (@fedora) libvpx.so.0()(64bit) Updated By: libvpx-1.0.0-1.fc16.x86_64 (updates) Not found In plain english, what this means is that you have packages installed from the atrpms repository which were built against the old libvpx package, specifically, mplayer, libavcodec52, and libavcodec53. To resolve this, you can either wait for atrpms to rebuild these packages against the libvpx update, or download the SRPMS and rebuild them on a Fedora 16 system which has the latest libvpx-devel package installed. (They should rebuild from SRPM without issue, but you may want to increment release to ensure a clean upgrade.) I can't prevent dependency failures in third-party repositories, so this is not a bug in Fedora (all libvpx deps in Fedora are resolved). #2. Your attempted "fix" for the libvpx package is completely incorrect. Don't do that, ever. #3. You attempted to update with rpm, but you used "rpm -ivh", which is the incorrect syntax for updating an already installed package. The syntax you want is "rpm -Uvh". When you ran rpm -ivh --force, what you did is force rpm to parallel install the new package alongside the old one, which is why you ended up with both sets of libraries.
Thank you Tom. Damn I hate it when my ignorance falls out of my mouth like that for everyone to see! Of course I *knew* that those packages came from Axel..but I completely failed to associate that with anything related to the upgrade process. "I can't prevent dependency failures in third-party repositories, so this is not a bug in Fedora (all libvpx deps in Fedora are resolved)." Absolutely correct. "#2. Your attempted "fix" for the libvpx package is completely incorrect. Don't do that, ever." Hah! You remind me of my mother! But then I say that to my clients, too! I told you I didn't know what I was doing. It didn't work, nor did it seem to make anything worse. It didn't seem to do anything, in fact. It is a bare metal install, so I figured I could lose an hour or 2 if it really went bad. I decided to play. That's part of the "F" in FOSS. "#3. You attempted to update with rpm, but you used "rpm -ivh", I tried 'Uvh' first, but it failed for the reasons you gave. THEN I tried to kick it into submission! Now I think I will re-build from the SRPMS, just for the hell of it. Keep up the good work. My apologies for having taken up your time.
(In reply to comment #3) > "#2. Your attempted "fix" for the libvpx package is completely incorrect. Don't > do that, ever." > > Hah! You remind me of my mother! But then I say that to my clients, too! > I told you I didn't know what I was doing. It didn't work, nor did it seem to > make anything worse. It didn't seem to do anything, in fact. It is a bare metal > install, so I figured I could lose an hour or 2 if it really went bad. I > decided to play. That's part of the "F" in FOSS. No worries, play leads to learning. :) In this specific scenario, it is important to remember that upstreams usually only increment the shared-object-revision number when the ABI has changed. They do this explicitly so that programs which were built against the old ABI cannot simply load the new shared library, because this will almost certainly lead to crashes or undefined behavior. What you attempted to do (create symlinks for the old shared-object-revision names) bypasses that, but worse still, it would tell rpm that it was providing the old shared-object-revision libraries for dependency resolution purposes, when it isn't really doing that! Hence, the "Don't do that, ever." :)