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.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). > (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? -- 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
