[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Mon Jan 26 22:19:29 CET 2009
Reinhard Tartler <siretart at tauware.de> writes:
> M?ns Rullg?rd <mans at mansr.com> writes:
>> Given that most of the complaints are invalid, e.g. the API hasn't
>> changed nearly as often as they say, there really isn't much we can
>> do. If people want to make up false claims about FFmpeg, and then
>> complain about them, they'll keep doing that no matter what we do.
> I have been bitten by this this week. Several bugs have been reported
> because of the recent ffmpeg update.
> The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
> already could clear up this issue. The rename was done to make the gcd
> function part of the public API; it was private before. However the
> *perception* of users is that ffmpeg has changed ABI/API. Why? Let me
> explain it:
> In debian lenny, ffmpeg is split in different binary packages, among
> others libavcodec51 and libavutil49 using a snapshot from february 2008
> . In experimental, I've now updated the an snapshot from last week
> end. Because of the version bump in libavcodec, I needed to rename the
> binary package libavcodec51 -> libavcodec52, which is standard practice
> in debian with SONAME bumps. The rename is done to assist transitioning
> programs linking against libavcodec51: Packages not yet recompiled
> against the newer ffmpeg are not instantly broken, because libavcodec51
> left on the hard disk. It is only removed if nothing else depends on it.
> Now something interesting happens: with the new ffmpeg snapshot
> libavutil is updated as well. It features a function rename
> (ff_gcd->av_gcd), which is according to the ffmpeg development policy
> OK, since it is a pure private function. However this rename breaks the
> libavcodec51 package horribly. 
In summary, you are blaming FFmpeg for difficulties caused by broken
packaging and silly policies in Debian. That's not really fair.
mans at mansr.com
More information about the ffmpeg-devel