[vlc-devel] [vlc-commits] commit: Force avcodec to be at least 52.25.0 and avfomat 52.30.0... ( Jean-Baptiste Kempf )

[Rémi Denis-Courmont]

Le mercredi 21 juillet 2010 22:22:13 Jean-Baptiste Kempf, vous avez écrit :
> On Wed, Jul 21, 2010 at 08:48:46PM +0200, Christophe Mutricy wrote :
> > On Wed, Jul 21, 10 at 18:20 +0200, Jean-Baptiste Kempf wrote:
> > > Though, I believe that having a more than year old libavcodec for a
> > > media player is quite annoying...
> > 
> > Well the stable 0.5 branch doesn't causes me troubles.
> > 
> > > Moreover, this blocks us from moving to the new decode functions...
> > 
> > If indeed we use newer/better functions it'll be worth. If it's just to
> > avoid some #ifdef, I think we penalize too many people for only
> > improving the code readability
> 
> I think debian is penalizing us :D

Well... waiting for Debian stable would be insane in some cases given how slow 
the release cycle is. And it's already been a long time since VLC wouldn't 
compile on pure Debian stable anymore. 
But in this case, you broke Sid also. I am now fine as newer FFmpeg is 
available in experimental. In fact, I wonder why Sid has so old an FFmpeg.

IMHO, the real problem is a lack of clear policy. This topic gets brought back 
just about everytime someone increases the version number requirements of an 
underlying library... I recall arguments about glibc, Qt4, autoconf, automake, 
FFmpeg, Fluidsynth, modplug, xcb-utils, alsa-lib, gettext, live555 just to 
name a few.

Obviously, increasing requirements just for the heck of being up-to-date is 
silly. On the other hand, keeping backward compatibility hacks forever, or 
letting users unwittingly build buggy VLC's is not good. But where do we draw 
the line? To play devil's advocate, I would argue we should depend on Qt4.7 
and alsa-lib 1.0.24 since they fix known VLC bugs. Nevermind that neither of 
them are even officially released yet...

-- 
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis