[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Michael Niedermayer]

On Mon, Jan 26, 2009 at 09:52:19PM +0100, Reinhard Tartler wrote:
> 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 the end this means that libavutil49 must not be renamed until *all*
> applications linking against any library of ffmpeg has been recompiled.
> We now are aware of the issue and in future, we will express this
> through package dependencies propoery, however the core issue stands:
> Transitions to a newer snapshot of ffmpeg are made terribly painful this
> way. Please note that the requirement to rebuild *all* reverse depends
> of a library like ffmpeg is really a problem [2] for distributions like
> debian or ubuntu.
> 
> I just tell you this story because I think it greatly contributes to the
> *perception* that ffmpeg changes its API/ABI too often. From a
> distribution POV, stories like these have the *same* *impact* as an
> API/ABI change.

1. why did you not tell this to us earlier
2. why did you not just add ff_gcd(){return av_gcd()} !?

in that sense, a patch doing 2. under #if ...VERSION < next major
is welcome!

IMHO the gcd issue is a bug on our side not the way we/i want to do things
when its avoidable

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090126/3027a69b/attachment.pgp>