Hi,
On 09.08.2015 12:57, Ronald S. Bultje wrote:
> Yeah, I'm with this. Andreas, the correct fix is to update applications,
> even if that means vendor-specific patches in Debian. These are
> exceptionally trivial patches that you can generate using fairly trivial
> sed scripting.
The problem is not that creating patches for these two API changes was
difficult, but that these affect the majority of API users.
> The same goes for other easily scriptable changes. These APIs are gone and
> I don't want them back.
What is your problem with keeping the trivial compatibility layers for
another year?
On 09.08.2015 13:00, Ronald S. Bultje wrote:
> Again, I'm with this. Babies learn to walk and talk in 2 years, we can't
> figure out how to sed a handful of packages in Debian in 2 years?
It is *not* just a handful of packages, but the majority of them.
If anyone had sent these a patch a year ago, most probably we wouldn't have
a problem now.
Keeping these two trivial APIs about halves the number of affected packages.
Removing them will create a huge amount of busywork for distributions, but
no real benefit for anyone.
It will also bring us a bad reputation for not providing a stable enough API.
> Scriptable API changes are out and stay out. Just script a patch in Debian.
> I can help you scripting it together if you can't figure it out yourself
> (something like find . -name *.[ch] -exec sed -i -e
> 's|PIX_FMT_|AV_PIX_FMT|g' {} \; and then a similar version for this change)
> should do the trick.
This script will miss some cases (*.cpp) and wreck all sorts of havoc
(AV_AV_PIX_FMT_*). But don't waste your time improving this script.
If you want to help, please document how avpicture_deinterlace
can be replaced in practice, that is in a project that doesn't use
libavfilter yet.
I'm also keen on getting rid of old API, but gratuitously breaking the
majority of API users is a really bad idea.
Instead, let's remove FF_API_MISSING_SAMPLE, which never had a use case
for other projects, or fix ffserver, so that the last public ff* symbols
can go from libavformat.
Best regards,
Andreas
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
