[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Michael Niedermayer]

On Tue, Jan 27, 2009 at 12:57:42AM +0100, Aurelien Jacobs wrote:
> Michael Niedermayer wrote:
> 
> > 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!
> 
> Trivial patch attached.

looks good

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

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- 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/20090127/f0576fc6/attachment.pgp>