On Thu, 6 Aug 2015 23:26:05 +0200 Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote:
> On 06.08.2015 00:53, wm4 wrote: > > Well, you sure like to list a lot of projects. > > No, I don't. I'd like it much more if the list was empty. > > > But what you don't say > > is that many of these are either definitely dead (mplayer2 comes to > > mind), > > One is not many. But OK, let's get rid of mplayer2 [1]. So why does mplayer2 have to die, but other projects are extremely important to keep and thus no deprecated API should be dropped? I didn't attempt to check how many projects really rely on deprecated features, but... > > or are ancient releases of software which fixed their API usage > > later (like my own project, and probably most other reasonable active > > projects). > > Now I'm curious what your own project is. > I thought you were involved with mpv, but that still uses the deprecated > FF_API_AUDIOCONVERT [2]. It is mpv. Yes, there are 3 audioconvert.h include statements, but usage of any of the symbols was removed almost 2.5 years ago. You only need a trivial patch to fix it. (Or make the upstream project aware. I didn't know about this, but removed the includes yesterday when I read your post. Why didn't I ever get a bug report from you about this?) How many more projects are there that can be trivially updated, but you weren't aware of? I also doubt that software like vlc, kodi, or chromium actually use deprecated API in their git development branches. Why do you want to compile old releases against bleeding edge libav/ffmpeg? > Projects like blender, gst-libav or mplayer are reasonably recent in Debian > and active upstream. But still they use deprecated APIs. > > > Why do we have to suffer because Debian tries to compile ancient > > releases against newer ffmpeg/libav releases? (How does that even make > > sense?) > > This is just your prejudice that doesn't have much to do with reality. I've had very much experience with distro reality. They tend to make everyone's life harder (including their own) by demanding that EVERY project uses the same libav* build. Well, if you want to do this, you're free to do so. But it's not our problem. Feel free to put as much effort into it as you like. > > And then there's the category of projects that are "alive", but barely > > care about anything unless being severely prodded. I'm not sure why we > > should suffer forever just to accommodate these projects. They had more > > than enough time. > > It's actually the other projects that have to suffer, because FFmpeg/Libav > breaks it's API. Time alone is not enough, there also needs to be good > documentation about API replacements and that is currently insufficient. This is all very tiring. We're trying to improve the APIs everyone likes to complain so much about. But staying compatible forever is just not feasible. It leads to accumulation of strange things, even if it's minor changes like the PIXFMT renames. Do you think anyone has it easier to develop a program using the libs when confronted with tons of legacy symbols? > > I feel like I'm repeating myself and others, but I don't remember > > whether you acknowledged these arguments. > > I'm seeing more dramatic words than good arguments in your mail. OK, let's be polemic: I'm seeing outright lies from you. Not nearly enough important software as you make it seem depends on deprecated features, and even if, many of them are trivially fixable. Of course older releases of them use deprecated features, because at the time they were not deprecated yet, or were still within the grace period. And I don't see why you see this as "proof". (Note that sometimes it's preferable to use deprecated features, because distros are on ancient libav* versions to keep unmaintained software depending on it going. This also very much sucks for the project authors, btw.) > >> Better documentation would surely be helpful. > > > > Many of these are non-trivial. Project authors either update their > > code, or the project dies. It's simple. If you don't want this, keep an > > old ffmpeg/libav package around for them. But you distro peoples want a > > single libavcodec package, no matter how much this fucking tortures > > everyone. > > So instead of keeping a little bit of deprecated code, everyone should > keep multiple copies of libavcodec? > This is several orders of magnitude worse. Why is it worse? Disk space is very cheap, and the libs aren't that big after all. But I know, you distro folks would rather waste a lot of time trying to make all projects use the same libs, instead of going the easy way. By the way, why the hell do I have to have two versions of Qt and 2 versions of Python on my Debian system? These are much heavier than libav*. > Best regards, > Andreas > > > 1: https://bugs.debian.org/794817 > 2: > https://github.com/mpv-player/mpv/blob/master/audio/filter/af_lavcac3enc.c#L29 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
