On 2015-07-30 17:38:07 +0200, Anton Khirnov wrote: > Quoting Andreas Cadhalpun (2015-07-30 17:05:12) > > Hi, > > > > On 28.07.2015 15:36, Vittorio Giovara wrote: > > > This set contains the removal of all deprecated features marked as > > > such until 2012/early 2013. This was announced several times in the > > > past months and agreed at several meetings (since fosdem and recently > > > at the sprint). > > > > > > With more than two year span, downstream users should have had enough > > > time to update their API usage (or comment otherwise). > > > > Unfortunately this is just wishful thinking. > > As it is, your proposed removal of deprecated features is going to break > > about three quarters of all packages using the libav* libraries in Debian: > > > > FF_API_PIX_FMT: 57 > > amide avbin avifile bino chromium-browser dff dolphin-emu dvswitch > > ffmpeg2theora ffmpegthumbnailer ffmpegthumbs fuse-emulator-utils > > gmerlin-avdecoder gmerlin-encoders gnash gpac gst-libav1.0 guvcview harvid > > hedgewars info-beamer karlyriceditor kodi lebiniou libam7xxx libavg libde265 > > libextractor libquicktime linphone lives lynkeos.app mlt mplayer mplayer2 > > opal > > openscenegraph ovito paraview performous pjproject qutecom rbdoom3bfg > > sflphone > > strigi survex transcode vtk vtk6 vxl wxsvg x264 xjadeo xpra yorick-av > > zoneminder > > > > FF_API_AVFRAME_LAVC: 19 > > acoustid-fingerprinter amarok aubio blender chromaprint dvbcut gazebo > > goldendict jugglemaster kino lightspark mrpt opencv shotdetect spek > > squeezelite vcmi vlc xine-lib-1.2 > > > > FF_API_AUDIOCONVERT: 5 > > alsa-plugins cantata ffdiaporama moc mpv > > > > FF_API_DESTRUCT_PACKET: 1 > > openmw > > > > FF_API_AVFILTERBUFFER: 1 > > pianobar > > > > Note that this is only counting one API per packet. > > > > Ideally you should make sure that patches for all of them are available, > > before these APIs get removed. > > > > Considering how widespread the use of FF_API_PIX_FMT and FF_API_AVFRAME_LAVC > > still is, it might make sense to delay their removal. > > Past experience indicates that if we wanted to wait for all (or even > most) of the downstreams to adapt before breaking compatiblity, we'd > have to wait forever. Most of then, unfortunately, have to be forced > into adopting the new APIs.
random silly idea: instead of deleting deprecated features keep them for another release but hidden under a define like AV_USE_REMOVED_FEATURES_WILL_BREAK_WITH_$VERSION_NEXT. That would result in compile errors by default and gives hopefully enough motivation to fix things while it allows distributions to compile not updated software against new libav. I'm not certain if it will have the desired effect but at least we could ignore every project which hardcaodes that define. Janne _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
