[vlc-devel] [vlc-commits] commit: Force avcodec to be at least 52.25.0 and avfomat 52.30.0... ( Jean-Baptiste Kempf )
remi at remlab.net
Wed Jul 21 21:35:38 CEST 2010
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...
More information about the vlc-devel