[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Måns Rullgård]

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
> [1]. 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. [3]

In summary, you are blaming FFmpeg for difficulties caused by broken
packaging and silly policies in Debian.  That's not really fair.

-- 
M?ns Rullg?rd
mans at mansr.com