F14, fully up to date before this. vlc installed.
# yum update Loaded plugins: changelog, downloadonly, kmdl, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check --> Processing Dependency: libdirect-1.4.so.0 for package: vlc-extras-1.1.7-1.fc14.i686 --> Processing Dependency: libdirectfb-1.4.so.0 for package: vlc-extras-1.1.7-1.fc14.i686 --> Processing Dependency: libfusion-1.4.so.0 for package: vlc-extras-1.1.7-1.fc14.i686 ---> Package directfb.i686 0:1.4.11-3.fc14 set to be updated ---> Package gnome-python2-extras.i686 0:2.25.3-29.fc14.1 set to be updated ---> Package gnome-python2-gtkhtml2.i686 0:2.25.3-29.fc14.1 set to be updated ---> Package gnome-python2-libegg.i686 0:2.25.3-29.fc14.1 set to be updated ---> Package libgadu.i686 0:1.10.1-1.fc14 set to be updated ---> Package libgnome-keyring.i686 0:2.32.0-2.fc14 set to be updated ---> Package libgnome-keyring-devel.i686 0:2.32.0-2.fc14 set to be updated ---> Package libv4l.i686 0:0.8.3-2.fc14 set to be updated ---> Package tcl.i686 1:8.5.9-1.fc14 set to be updated ---> Package tk.i686 1:8.5.9-1.fc14 set to be updated ---> Package xine-lib.i686 0:1.1.19-2.fc14.2 set to be updated ---> Package xine-lib-extras.i686 0:1.1.19-2.fc14.2 set to be updated ---> Package xulrunner.i686 0:1.9.2.16-1.fc14 set to be updated ---> Package xulrunner-devel.i686 0:1.9.2.16-1.fc14 set to be updated --> Finished Dependency Resolution DEBUG: [] Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates) Requires: libfusion-1.4.so.0 Removing: directfb-1.4.11-2.fc14.i686 (@updates) libfusion-1.4.so.0 Updated By: directfb-1.4.11-3.fc14.i686 (updates) Not found Available: directfb-1.4.3-1.fc14.i686 (fedora) libfusion-1.4.so.0 Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates) Requires: libdirect-1.4.so.0 Removing: directfb-1.4.11-2.fc14.i686 (@updates) libdirect-1.4.so.0 Updated By: directfb-1.4.11-3.fc14.i686 (updates) Not found Available: directfb-1.4.3-1.fc14.i686 (fedora) libdirect-1.4.so.0 Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates) Requires: libdirectfb-1.4.so.0 Removing: directfb-1.4.11-2.fc14.i686 (@updates) libdirectfb-1.4.so.0 Updated By: directfb-1.4.11-3.fc14.i686 (updates) Not found Available: directfb-1.4.3-1.fc14.i686 (fedora) libdirectfb-1.4.so.0 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
On 03/24/2011 06:06 PM, Linuxguy123 wrote:
F14, fully up to date before this. vlc installed.
# yum update Loaded plugins: changelog, downloadonly, kmdl, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check --> Processing Dependency: libdirect-1.4.so.0 for package: vlc-extras-1.1.7-1.fc14.i686 --> Processing Dependency: libdirectfb-1.4.so.0 for package: vlc-extras-1.1.7-1.fc14.i686 --> Processing Dependency: libfusion-1.4.so.0 for package: vlc-extras-1.1.7-1.fc14.i686 ---> Package directfb.i686 0:1.4.11-3.fc14 set to be updated ---> Package gnome-python2-extras.i686 0:2.25.3-29.fc14.1 set to be updated ---> Package gnome-python2-gtkhtml2.i686 0:2.25.3-29.fc14.1 set to be updated ---> Package gnome-python2-libegg.i686 0:2.25.3-29.fc14.1 set to be updated ---> Package libgadu.i686 0:1.10.1-1.fc14 set to be updated ---> Package libgnome-keyring.i686 0:2.32.0-2.fc14 set to be updated ---> Package libgnome-keyring-devel.i686 0:2.32.0-2.fc14 set to be updated ---> Package libv4l.i686 0:0.8.3-2.fc14 set to be updated ---> Package tcl.i686 1:8.5.9-1.fc14 set to be updated ---> Package tk.i686 1:8.5.9-1.fc14 set to be updated ---> Package xine-lib.i686 0:1.1.19-2.fc14.2 set to be updated ---> Package xine-lib-extras.i686 0:1.1.19-2.fc14.2 set to be updated ---> Package xulrunner.i686 0:1.9.2.16-1.fc14 set to be updated ---> Package xulrunner-devel.i686 0:1.9.2.16-1.fc14 set to be updated --> Finished Dependency Resolution DEBUG: [] Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates) Requires: libfusion-1.4.so.0 Removing: directfb-1.4.11-2.fc14.i686 (@updates) libfusion-1.4.so.0 Updated By: directfb-1.4.11-3.fc14.i686 (updates) Not found Available: directfb-1.4.3-1.fc14.i686 (fedora) libfusion-1.4.so.0 Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates) Requires: libdirect-1.4.so.0 Removing: directfb-1.4.11-2.fc14.i686 (@updates) libdirect-1.4.so.0 Updated By: directfb-1.4.11-3.fc14.i686 (updates) Not found Available: directfb-1.4.3-1.fc14.i686 (fedora) libdirect-1.4.so.0 Error: Package: vlc-extras-1.1.7-1.fc14.i686 (@rpmfusion-free-updates) Requires: libdirectfb-1.4.so.0 Removing: directfb-1.4.11-2.fc14.i686 (@updates) libdirectfb-1.4.so.0 Updated By: directfb-1.4.11-3.fc14.i686 (updates) Not found Available: directfb-1.4.3-1.fc14.i686 (fedora) libdirectfb-1.4.so.0 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest
I'm seeing the same thing, but when I try and update directfb, and the conflicts I'm seeing are with: xine-libs and mplayer.
--> Running transaction check --> Processing Dependency: libdirect-1.4.so.0()(64bit) for package: xine-lib-1.1.19-22.fc14.x86_64 --> Processing Dependency: libdirectfb-1.4.so.0()(64bit) for package: 4:mplayer-1.0-80_snap20110221.fc14.x86_64 --> Processing Dependency: libdirectfb-1.4.so.0()(64bit) for package: xine-lib-1.1.19-22.fc14.x86_64 --> Processing Dependency: libfusion-1.4.so.0()(64bit) for package: xine-lib-1.1.19-22.fc14.x86_64 ---> Package directfb.x86_64 0:1.4.11-3.fc14 set to be updated --> Finished Dependency Resolution Error: Package: xine-lib-1.1.19-22.fc14.x86_64 (@anaconda-InstallationRepo-201010211827.x86_64) Requires: libfusion-1.4.so.0()(64bit) Removing: directfb-1.4.11-2.fc14.x86_64 (@updates) libfusion-1.4.so.0()(64bit) Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libfusion-1.4.so.0()(64bit) Error: Package: xine-lib-1.1.19-22.fc14.x86_64 (@anaconda-InstallationRepo-201010211827.x86_64) Requires: libdirect-1.4.so.0()(64bit) Removing: directfb-1.4.11-2.fc14.x86_64 (@updates) libdirect-1.4.so.0()(64bit) Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libdirect-1.4.so.0()(64bit) Error: Package: 4:mplayer-1.0-80_snap20110221.fc14.x86_64 (@atrpms) Requires: libdirectfb-1.4.so.0()(64bit) Removing: directfb-1.4.11-2.fc14.x86_64 (@updates) libdirectfb-1.4.so.0()(64bit) Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libdirectfb-1.4.so.0()(64bit) Error: Package: xine-lib-1.1.19-22.fc14.x86_64 (@anaconda-InstallationRepo-201010211827.x86_64) Requires: libdirectfb-1.4.so.0()(64bit) Removing: directfb-1.4.11-2.fc14.x86_64 (@updates) libdirectfb-1.4.so.0()(64bit) Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libdirectfb-1.4.so.0()(64bit) You could try using --skip-broken to work around the problem
Yet another well tested update. B^) And a bunch of dependencies with = Requires instead of >= Requires.
Seems the new directfb package is now providing libdirectfb-1.4.so.5 instead of libdirectfb-1.4.so.0 .....
--skip-broken will update everything else, but the problem with directfb remains.
On Thu, 24 Mar 2011 18:48:53 -0400, Kevin wrote:
Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libdirectfb-1.4.so.0()(64bit)You could try using --skip-broken to work around the problem
Yet another well tested update. B^) And a bunch of dependencies with = Requires instead of >= Requires.
Seems the new directfb package is now providing libdirectfb-1.4.so.5 instead of libdirectfb-1.4.so.0 .....
--skip-broken will update everything else, but the problem with directfb remains.
Not really. Unless it breaks something in Fedora's repos. The problem is with vlc, because RPM Fusion can only build against the new directfb if it appears in Fedora stable Updates repo.
https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1....
On 03/24/2011 07:16 PM, Michael Schwendt wrote:
On Thu, 24 Mar 2011 18:48:53 -0400, Kevin wrote:
Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libdirectfb-1.4.so.0()(64bit)You could try using --skip-broken to work around the problem
Yet another well tested update. B^) And a bunch of dependencies with = Requires instead of >= Requires.
Seems the new directfb package is now providing libdirectfb-1.4.so.5 instead of libdirectfb-1.4.so.0 .....
--skip-broken will update everything else, but the problem with directfb remains.
Not really. Unless it breaks something in Fedora's repos. The problem is with vlc, because RPM Fusion can only build against the new directfb if it appears in Fedora stable Updates repo.
Hey, I never said which packages were at fault. I actually complained about the = dependencies instead of >= (which should have not then been a problem). I didn't bother to check which repos built xine-lib or mplayer on my system. Yeup, both were built by ATRPMS. B^) (and it looks like linuxguy123's vlc-extras packages comes from rpmfusion.)
And I disagree about other repos not being able to build against a package unless it is in Fedora stable. That's what Fedora updates-testing, atrpms-testing, rpmfusion-free-updates-testing, and rpmfusion-nonfree-updates-testing repos are all about. Then when fedora pushes a package to stable, all the other repos have to do is push their dependent packages to their stable repos as well. Its called planned cooperation. I thought it was already going on. I never had this problem getting a new nvidia or fglrx kernel driver from them any time a new kernel gets released. How is this different? (Maybe because the nvidia and fglrx builders were more diligent about checking updates-testing for upcoming releases?)
https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1....
Wow. 3 for, 3 against, a total Karma of 1, and they pushed to stable (looks like because it had stayed in testing for 7 days. Just because 7 days had lapsed, it doesn't mean the update gets better, does it?) Doesn't seem very overwhelmingly confident....
It looks like they knew there were still problems with the update, and didn't care. OTOH, if they did poke the other maintainers and got no response, I can't blame them very much. Ouch.
On Thu, 2011-03-24 at 23:47 -0400, Kevin J. Cummings wrote: <snip>
I appreciate the discussion on this situation. I really didn't mean to stir up the hornet's nest on this.
The good news is that a) yum works incredibly well at sorting out the situation and allows everything else to update in spite of the vlc issue and b) vlc still works.
We don't live in a perfect Linux world, but its still a very good one.
On Thu, 24 Mar 2011 23:47:30 -0400, Kevin wrote:
On 03/24/2011 07:16 PM, Michael Schwendt wrote:
On Thu, 24 Mar 2011 18:48:53 -0400, Kevin wrote:
Updated By: directfb-1.4.11-3.fc14.x86_64 (updates) Not found Available: directfb-1.4.3-1.fc14.x86_64 (fedora) libdirectfb-1.4.so.0()(64bit)You could try using --skip-broken to work around the problem
Yet another well tested update. B^) And a bunch of dependencies with = Requires instead of >= Requires.
Seems the new directfb package is now providing libdirectfb-1.4.so.5 instead of libdirectfb-1.4.so.0 .....
--skip-broken will update everything else, but the problem with directfb remains.
Not really. Unless it breaks something in Fedora's repos. The problem is with vlc, because RPM Fusion can only build against the new directfb if it appears in Fedora stable Updates repo.
Hey, I never said which packages were at fault. I actually complained about the = dependencies instead of >= (which should have not then been a problem).
You haven't shown any such '=' dependencies. The thread only quotes unresolvable SONAME dependencies. And those are "equal to" by definition.
I didn't bother to check which repos built xine-lib or mplayer on my system. Yeup, both were built by ATRPMS. B^) (and it looks like linuxguy123's vlc-extras packages comes from rpmfusion.)
And I disagree about other repos not being able to build against a package unless it is in Fedora stable.
We're talking past eachother. I refer to what RPM Fusion has been doing so far, not to what they _could_ do. It's a matter of how the 3rd party's build-system is set up and what it can do. As the most simple but unsafe solution, they would need to make available additional build targets that include Fedora's updates-testing repo. Not even Fedora does that. Test updates are not included in Fedora's koji buildroots used for building updates. With Fedora's process for stable distribution releases, one can ask the Release Engineering team to make available new packages in a buildroot, if one plans to build against them. Else the buildroot only contains packages from the released distribution plus stable updates. This adds some overhead, but helps with keeping the buildroot stable with regard to various concerns.
That's what Fedora updates-testing, atrpms-testing, rpmfusion-free-updates-testing, and rpmfusion-nonfree-updates-testing repos are all about. Then when fedora pushes a package to stable, all the other repos have to do is push their dependent packages to their stable repos as well.
That would require the third party repos to prepare their test updates based on Fedora's updates-testing repo contents. With no guarantee that all of the packages in updates-testing, which would be built against, are good and will be released actually.
Alternatively, they would need to find a way how to build against Fedora's koji buildroot package set. Dunno whether there's a reliable way to mirror that (and quickly enough in order to be up-to-date with regard to builds being added to [and removed from] it either automatically or by Fedora releng).
Its called planned cooperation. I thought it was already going on.
Not enough man-power. To do it painstakingly would create a lot of overhead for Fedora package maintainers.
I never had this problem getting a new nvidia or fglrx kernel driver from them any time a new kernel gets released. How is this different? (Maybe because the nvidia and fglrx builders were more diligent about checking updates-testing for upcoming releases?)
Yes, as far as I know, there has been some special effort at rebuilding and pushing kernel related addons as early as _possible_, which makes the broken deps a matter of a few hours only. Where broken dependencies block updates from being installed, it's no big issue anyway, provided that people are working on publishing the missing updates.
https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1....
Wow. 3 for, 3 against, a total Karma of 1,
Not "3 for, 3 against". That's just the karma threshold configuration for this update ticket. The update needs either +3 points to publish it before 7 days have passed or -3 points to remove it from updates-testing. It has received +1 from the packager (and +1 from an anonymous voter).
(looks like because it had stayed in testing for 7 days. Just because 7 days had lapsed, it doesn't mean the update gets better, does it?) Doesn't seem very overwhelmingly confident....
It looks like they knew there were still problems with the update, and didn't care.
Or the update is fine as is, but the problem at RPM Fusion having to wait for it to be marked stable remains. ;)
OTOH, if they did poke the other maintainers and got no response, I can't blame them very much. Ouch.
Why haven't you spent any karma points on that test update?
On 03/25/2011 05:39 AM, Michael Schwendt wrote:
You haven't shown any such '=' dependencies. The thread only quotes unresolvable SONAME dependencies. And those are "equal to" by definition.
Now, your mixing up semantic meaning. Being dependent upon a particular .so library release is the same as an = depends. When that library version gets updated to a newer version, it *will* break the dependency, regardless of whether the program will work or not work with the updated library. That is one of the reasons named dependencies exist. If the dependency were to be written as Requires directfb >= 1.4.3 then this problem wouldn't exist. Yes, I understand that package maintainers can't guarantee that a future library release won't bork the API into making the program fail. That's a different can of worms that developers need to learn about. Changing an ABI is a *BAD* thing to do. Yet, it happens all the time in Linux. That doesn't make it right, it just makes it a fact of life.
I didn't bother to check which repos built xine-lib or mplayer on my system. Yeup, both were built by ATRPMS. B^) (and it looks like linuxguy123's vlc-extras packages comes from rpmfusion.)
And I disagree about other repos not being able to build against a package unless it is in Fedora stable.
We're talking past eachother. I refer to what RPM Fusion has been doing so far, not to what they _could_ do. It's a matter of how the 3rd party's build-system is set up and what it can do. As the most simple but unsafe solution, they would need to make available additional build targets that include Fedora's updates-testing repo. Not even Fedora does that. Test updates are not included in Fedora's koji buildroots used for building updates. With Fedora's process for stable distribution releases, one can ask the Release Engineering team to make available new packages in a buildroot, if one plans to build against them. Else the buildroot only contains packages from the released distribution plus stable updates. This adds some overhead, but helps with keeping the buildroot stable with regard to various concerns.
You're fixated with RPMFusion. B^) (Given the subject of this thread, I can't blame you for that.) I have submitted my problem to ATRPMs (that's where *my* problem with this update lies). You don't want to know what one of the ATRPMS maintainers said about the Fedora directfb maintainer. B^)
That would require the third party repos to prepare their test updates based on Fedora's updates-testing repo contents. With no guarantee that all of the packages in updates-testing, which would be built against, are good and will be released actually.
I thought that's why it was a -testing repo.
Alternatively, they would need to find a way how to build against Fedora's koji buildroot package set. Dunno whether there's a reliable way to mirror that (and quickly enough in order to be up-to-date with regard to builds being added to [and removed from] it either automatically or by Fedora releng).
I don't think that's the way to go. Too complicated, and koji stuff is less stable than -testing. Perhaps its more equivalent to the atrpms -bleeding stuff?
Its called planned cooperation. I thought it was already going on.
Not enough man-power. To do it painstakingly would create a lot of overhead for Fedora package maintainers.
OK, so we need more volunteers....
https://admin.fedoraproject.org/updates/directfb-1.4.11-3.fc14,xine-lib-1.1....
Wow. 3 for, 3 against, a total Karma of 1,
Not "3 for, 3 against". That's just the karma threshold configuration for this update ticket. The update needs either +3 points to publish it before 7 days have passed or -3 points to remove it from updates-testing. It has received +1 from the packager (and +1 from an anonymous voter).
That wasn't immediately clear to me from glancing at the URL you provided. Yes, I understand its intended for developers who probably understand the system better than I do, but if you're going to start passing it around to non-developers, perhaps it should be clearer....
And +2 after 7 days still sounds like insufficient testing to me.
(looks like because it had stayed in testing for 7 days. Just because 7 days had lapsed, it doesn't mean the update gets better, does it?) Doesn't seem very overwhelmingly confident....
It looks like they knew there were still problems with the update, and didn't care.
Or the update is fine as is, but the problem at RPM Fusion having to wait for it to be marked stable remains. ;)
I'm not convinced. But, you are entitled to your opinion as much as I am entitled to mine.
OTOH, if they did poke the other maintainers and got no response, I can't blame them very much. Ouch.
Why haven't you spent any karma points on that test update?
I don't usually install from -testing, the lone exception is when the stable stuff is broken and the -testing package contains the fixes for the brokenness. And by the time I'm usually done testing, its been pushed to stable anyways. B^)
On Fri, 25 Mar 2011 13:42:09 -0400, Kevin wrote:
On 03/25/2011 05:39 AM, Michael Schwendt wrote:
You haven't shown any such '=' dependencies. The thread only quotes unresolvable SONAME dependencies. And those are "equal to" by definition.
Now, your mixing up semantic meaning. Being dependent upon a particular .so library release is the same as an = depends. When that library version gets updated to a newer version, it *will* break the dependency, regardless of whether the program will work or not work with the updated library. That is one of the reasons named dependencies exist.
You show a clear misunderstanding of automatic SONAME dependencies.
If the dependency were to be written as Requires directfb >= 1.4.3 then this problem wouldn't exist.
False. Due to the changed SONAME, the program would not even start. The dynamic linker would fail to find the "old" library. That's why the dependency is on a specific SONAME and not ">=".
You're fixated with RPMFusion. B^) (Given the subject of this thread, I can't blame you for that.)
False, too. RPM Fusion just serves as an example of a 3rd party repository when discussing [broken] dependencies.
That would require the third party repos to prepare their test updates based on Fedora's updates-testing repo contents. With no guarantee that all of the packages in updates-testing, which would be built against, are good and will be released actually.
I thought that's why it was a -testing repo.
Sure, but if you've built against _all_ of -testing, how do you know you can release part of -testing and/or withdraw part of testing without pulling anything that has been built against? You can't. It needs a well-defined "stable" buildroot of packages to build against. -testing can't be included.
Alternatively, they would need to find a way how to build against Fedora's koji buildroot package set. Dunno whether there's a reliable way to mirror that (and quickly enough in order to be up-to-date with regard to builds being added to [and removed from] it either automatically or by Fedora releng).
I don't think that's the way to go. Too complicated, and koji stuff is less stable than -testing. Perhaps its more equivalent to the atrpms -bleeding stuff?
Huh? Again you show that you don't know what you're talking of. "koji" is just the name of the software that is Fedora's build system. It cannot be "less stable than -testing" -- that doesn't make any sense at all to say that. It seems you refer to downloading _unpublished_ builds found within koji. That's a completely unrelated topic.
Not "3 for, 3 against". That's just the karma threshold configuration for this update ticket. The update needs either +3 points to publish it before 7 days have passed or -3 points to remove it from updates-testing. It has received +1 from the packager (and +1 from an anonymous voter).
That wasn't immediately clear to me from glancing at the URL you provided. Yes, I understand its intended for developers who probably understand the system better than I do, but if you're going to start passing it around to non-developers, perhaps it should be clearer....
Not true. The Fedora Updates System does not target developers. It targets the entire Fedora community.
And +2 after 7 days still sounds like insufficient testing to me.
Don't generalise.
On 03/25/2011 12:25 PM, Michael Schwendt wrote:
False. Due to the changed SONAME, the program would not even start. The dynamic linker would fail to find the "old" library. That's why the dependency is on a specific SONAME and not ">=".
I'm not quite sure I understand this. Are you saying that the dependency is on a specific version, not *at least* a specific version because the developer doesn't want to take the chance that some needed feature isn't backward compatible? If not, why be so fussy? (Please note that this isn't meant as a challenge; I'm sure there's a good reason that I'm not aware of.)
On Fri, 25 Mar 2011 13:13:43 -0700, Joe wrote:
False. Due to the changed SONAME, the program would not even start. The dynamic linker would fail to find the "old" library. That's why the dependency is on a specific SONAME and not ">=".
I'm not quite sure I understand this. Are you saying that the dependency is on a specific version, not *at least* a specific version because the developer doesn't want to take the chance that some needed feature isn't backward compatible? If not, why be so fussy? (Please note that this isn't meant as a challenge; I'm sure there's a good reason that I'm not aware of.)
It *is* a challenge, because if I understand your questions correctly [and based on your word choice], I would need to start from the bottom up. How much do you know about dynamically linked executables, shared libraries and versioning schemes, and [automatically added ] shared library dependencies with regard to RPM packaging? If you say "version", what do you refer to?
Also, which "developer" do you refer to? The library developer? The application developer (the app that uses a lib)? The package developer?
On 03/25/2011 03:02 PM, Michael Schwendt wrote:
It*is* a challenge, because if I understand your questions correctly [and based on your word choice], I would need to start from the bottom up. How much do you know about...
Yes, but it's not as though I were calling the practice stupid or anything. I used to be a programmer, back in the '80s and did some work on software utilities in FORTRAN at JPL with the late Dan Alderson. (Jerry Pournelle once called Dan the "sane genius," btw.) I'm not looking for a highly technical explanation, partly because I suspect that if I were, I'd already know the answer. I am curious, however, and a fairly general explanation might even be helpful to the OP. Of course, if there's no way to explain without going into TMI, that's OK too.
On Fri, 2011-03-25 at 15:09 -0700, Joe Zeff wrote: <snip>
I'm happy to report that this problem now appears to be solved.
# yum update Loaded plugins: changelog, downloadonly, kmdl, refresh-packagekit Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package directfb.i686 0:1.4.11-3.fc14 set to be updated ---> Package kbackup.i686 0:0.7.1-1.fc14 set to be updated ---> Package libcgroup.i686 0:0.36.2-6.fc14 set to be updated ---> Package rawstudio.i686 0:1.2-10.fc14.20110226svn3835 set to be updated ---> Package vlc.i686 0:1.1.8-1.fc14 set to be updated ---> Package vlc-core.i686 0:1.1.8-1.fc14 set to be updated ---> Package vlc-devel.i686 0:1.1.8-1.fc14 set to be updated ---> Package vlc-extras.i686 0:1.1.8-1.fc14 set to be updated ---> Package vlc-plugin-jack.i686 0:1.1.8-1.fc14 set to be updated ---> Package xine-lib.i686 0:1.1.19-2.fc14.2 set to be updated ---> Package xine-lib-extras.i686 0:1.1.19-2.fc14.2 set to be updated --> Finished Dependency Resolution DEBUG: []
Dependencies Resolved
===================================================================================================================================================================================== Package Arch Version Repository Size ===================================================================================================================================================================================== Updating: directfb i686 1.4.11-3.fc14 updates 1.2 M kbackup i686 0.7.1-1.fc14 updates 555 k libcgroup i686 0.36.2-6.fc14 updates 92 k rawstudio i686 1.2-10.fc14.20110226svn3835 updates 770 k vlc i686 1.1.8-1.fc14 rpmfusion-free-updates 1.9 M vlc-core i686 1.1.8-1.fc14 rpmfusion-free-updates 7.8 M vlc-devel i686 1.1.8-1.fc14 rpmfusion-free-updates 161 k vlc-extras i686 1.1.8-1.fc14 rpmfusion-free-updates 47 k vlc-plugin-jack i686 1.1.8-1.fc14 rpmfusion-free-updates 45 k xine-lib i686 1.1.19-2.fc14.2 updates 2.3 M xine-lib-extras i686 1.1.19-2.fc14.2 updates 70 k
Transaction Summary ===================================================================================================================================================================================== Upgrade 11 Package(s)
Total download size: 15 M Is this ok [y/N]: y Downloading Packages: (1/11): directfb-1.4.11-3.fc14.i686.rpm | 1.2 MB 00:03 (2/11): kbackup-0.7.1-1.fc14.i686.rpm | 555 kB 00:01 (3/11): libcgroup-0.36.2-6.fc14.i686.rpm | 92 kB 00:00 (4/11): rawstudio-1.2-10.fc14.20110226svn3835.i686.rpm | 770 kB 00:01 (5/11): vlc-1.1.8-1.fc14.i686.rpm | 1.9 MB 00:02 (6/11): vlc-core-1.1.8-1.fc14.i686.rpm | 7.8 MB 00:08 (7/11): vlc-devel-1.1.8-1.fc14.i686.rpm | 161 kB 00:00 (8/11): vlc-extras-1.1.8-1.fc14.i686.rpm | 47 kB 00:00 (9/11): vlc-plugin-jack-1.1.8-1.fc14.i686.rpm | 45 kB 00:00 (10/11): xine-lib-1.1.19-2.fc14.2.i686.rpm | 2.3 MB 00:02 (11/11): xine-lib-extras-1.1.19-2.fc14.2.i686.rpm | 70 kB 00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 666 kB/s | 15 MB 00:22 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Updating : vlc-core-1.1.8-1.fc14.i686 1/22 Updating : directfb-1.4.11-3.fc14.i686 2/22 Updating : xine-lib-1.1.19-2.fc14.2.i686 3/22 Updating : xine-lib-extras-1.1.19-2.fc14.2.i686 4/22 Updating : vlc-extras-1.1.8-1.fc14.i686 5/22 Updating : vlc-plugin-jack-1.1.8-1.fc14.i686 6/22 Updating : vlc-1.1.8-1.fc14.i686 7/22 Updating : rawstudio-1.2-10.fc14.20110226svn3835.i686 8/22 Updating : kbackup-0.7.1-1.fc14.i686 9/22 Updating : libcgroup-0.36.2-6.fc14.i686 10/22 Updating : vlc-devel-1.1.8-1.fc14.i686 11/22 Cleanup : xine-lib-extras-1.1.19-2.fc14.1.i686 12/22 Cleanup : vlc-extras-1.1.7-1.fc14.i686 13/22 Cleanup : vlc-1.1.7-1.fc14.i686 14/22 Cleanup : vlc-plugin-jack-1.1.7-1.fc14.i686 15/22 Cleanup : directfb-1.4.11-2.fc14.i686 16/22 Cleanup : xine-lib-1.1.19-2.fc14.1.i686 17/22 Cleanup : rawstudio-1.2-6.fc14.20100907svn3521.i686 18/22 Cleanup : kbackup-0.6.4-1.fc14.i686 19/22 Cleanup : libcgroup-0.36.2-5.fc14.i686 20/22 Cleanup : vlc-devel-1.1.7-1.fc14.i686 21/22 Cleanup : vlc-core-1.1.7-1.fc14.i686 22/22
Updated: directfb.i686 0:1.4.11-3.fc14 kbackup.i686 0:0.7.1-1.fc14 libcgroup.i686 0:0.36.2-6.fc14 rawstudio.i686 0:1.2-10.fc14.20110226svn3835 vlc.i686 0:1.1.8-1.fc14 vlc-core.i686 0:1.1.8-1.fc14 vlc-devel.i686 0:1.1.8-1.fc14 vlc-extras.i686 0:1.1.8-1.fc14 vlc-plugin-jack.i686 0:1.1.8-1.fc14 xine-lib.i686 0:1.1.19-2.fc14.2 xine-lib-extras.i686 0:1.1.19-2.fc14.2
Complete!
On 03/25/2011 06:25 PM, Linuxguy123 wrote:
On Fri, 2011-03-25 at 15:09 -0700, Joe Zeff wrote:
<snip>
I'm happy to report that this problem now appears to be solved.
Yes, both RPMFusion and ATRPMs have released updated versions that will now work with the released directfb package.
On 26 March 2011 01:59, Kevin J. Cummings cummings@kjchome.homeip.net wrote:
On 03/25/2011 06:25 PM, Linuxguy123 wrote:
On Fri, 2011-03-25 at 15:09 -0700, Joe Zeff wrote:
<snip>
I'm happy to report that this problem now appears to be solved.
Yes, both RPMFusion and ATRPMs have released updated versions that will now work with the released directfb package.
Interesting thread :-) What you should take from this if you depend on 3rd party repos is, If it aint fixed in a few days, just wait longer :-) patience I think they call it.
And dude your messin with the broken deps master you will lose, so prepare to be schooled 8-)
...dex
On Fri, 25 Mar 2011 15:09:43 -0700, Joe wrote:
It*is* a challenge, because if I understand your questions correctly [and based on your word choice], I would need to start from the bottom up. How much do you know about...
Yes, but it's not as though I were calling the practice stupid or anything. I used to be a programmer, back in the '80s and did some work on software utilities in FORTRAN at JPL with the late Dan Alderson. (Jerry Pournelle once called Dan the "sane genius," btw.) I'm not looking for a highly technical explanation, partly because I suspect that if I were, I'd already know the answer. I am curious, however, and a fairly general explanation might even be helpful to the OP. Of course, if there's no way to explain without going into TMI, that's OK too.
I'm a little bit concerned about whether you might be biased already [with regard to considering broken dependencies as a bad thing].
The executable's dependency is on a specific library "interface" it was linked with at compile-time (= package build-time).
Imagine an "identifier", such as "libbz2.so.1" for the bzip2 compression library. Sort of a combination of the library name and its interface [major] version. (I won't comment on ABI/API here due to time constraints and due to complexity of the topic.) It is not a file name, even if the bzip2-libs package contains a file with that name. The indentifier is stored inside the library, but is exposed to the run-time linker, which looks up a library based on its "identifier". Messing with the file name (or symlinks to it) doesn't change the identifier - which means, more often than not you cannot get a new incompatible library to work with older programs _without_ recompiling and relinking them appropriately.
For most programs, the dependency on a library identifier is added to the RPM package automatically by rpmbuild when building the RPM package. The dependency is not added manually by the package maintainer.
It is within the library author's responsibilities to maintain compatibility when releasing updates to the library. Usually, the Fedora packagers do not question the library authors' decision whether and when to release incompatible library updates. (Though it happens that some authors don't get it right, or don't care about interface stability at all - sometimes even deliberately - or that Fedora packagers don't notice the incompatible interface.)
The library developers may issue a release, which justifies changing the interface and its identifier, so that programs (and packages) would need to be rebuilt. (It could even be that, as a last resort, behavioral changes to a library require a program to be modified as well. And with interface changes, the library authors can force the program authors to catch up.)
If the Fedora packager releases an incompatible library package, RPM protects the users. It recognizes that the new library package will break dependencies of installed packages. Hence it refuses to install the incompatible library package. Only way to break your system then is to override RPM's decision, and Yum is smart enough not to provide a --nodeps option. Broken dependencies are a good thing. Provided that the package developers monitor them carefully and take proper action to resolve the issues - by either withdrawing the incompatible packages or by rebuilding other packages where necessary.
Hope this very introductory explanation is not too technical. Questions?
-
dexter -
Joe Zeff -
Kevin Cummings -
linux guy -
Michael Schwendt