Re: F14 vlc update problem.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux