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.19-2.fc14.2 >> >> 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^) -- Kevin J. Cummings kjchome@xxxxxxxxxxx cummings@xxxxxxxxxxxxxxxxxx cummings@xxxxxxxxxxxxxxxxxxxxxxx Registered Linux User #1232 (http://counter.li.org) -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
