Bug#732159: Should this package be removed?

Wed Feb 19 13:24:01 UTC 2014

TBH, I'm a bit confused about your reply.

On Mon, Feb 17, 2014 at 6:52 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sun, Feb 16, 2014 at 03:25:08PM -0500, Reinhard Tartler wrote:
>> On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
>> <Reimar.Doeffinger at gmx.de> wrote:
>> > What would constitute a constructive comment?
>>
>> Ideally "I am interested in making mplayer work against the libavcodec
>> that we have in Debian, and this is my work in progress".
>
> Well, I expect that making it build wouldn't be that hard, but it
> would be quite crippled and broken,
> and with the limited effort I
> am willing to spend on getting patches into Libav I won't be getting
> anywhere I would conclude from previous tries.

I take this as that you (as upstream) do not want mplayer to be
compiled against libav. That's a strong argument *for* removing it
from Debian, which ships this version of libav, *and* has working and
non-crippled alternatives to mplayer in the archive.

Besides, has development and support for mencoder been revived, or do
its developers still consider mencoder deprecated and/or obsolete?
AFAIR, people on the mencoder/mplayer mailing lists have recommended
to just use the command-line tool ffmpeg/avconv instead for a couple
of years now.

>> > mplayer2 is unmaintained and as far as I can tell mpv has completely
>> > different command-line syntax at the least (though I am not well
>> > informed about either).
>>
>> It was my sincere hope that this would be a sufficient incentive and
>> motivation to work on keeping mplayer/mencoder in debian.
>> Unfortunately, it seems I was wrong.
>
> Well, it was motivation to suggest several ways to get FFmpeg into
> Debian, since that is kind of the most realistic way to solve it,
> also since otherwise it won't be the version of MPlayer that
> is tested upstream.
> However so far this seems to be considered completely out of the
> question.

Sorry, but taking mplayer as political argument to make pressure on
the FFmpeg vs. Libav conflict is not going to help anyone. Please have
this discussion elsewhere, e.g. in  #729203.

> Which for me kind of leaves the question if the best MPlayer we
> can offer under these circumstances is worth it.

I guess the conclusion of this discussion tends to "no", although we
disagree on the rationale. That's fair enough with me.

>> > Libav compatibility is not intentionally broken upstream, but it
>> > is not tested in any systematic way either (possibly not at all).
>>
>> This is not the primary concern or reason in the context of whether or
>> not to remove mplayer/mencoder from Debian. The reason is that there
>> is nobody who is interested enough to work on making it suitable in
>> Debian. Otherwise we wouldn't have to remove the package from
>> Debian/testing (jessie).
>
> This sounds to me like you see a difference between "Libav
> compatibility" and "suitable in Debian"?
> I'd be interested in that.

Please contact me again in private about this. Let's keep this bug
focused on arguments pro and contra removal of mplayer/mencoder from
Debian.

>> Personal remark here: mplayer was always problematic in Debian. Up to
>> today, it is not possible to even compile mplayer without removing its
>> internal copy of ffmpeg.
>
> Yes, no, maybe. I just looked into it. You have to provide matching
> copies of libavformat/internal.h (can be eliminated reasonably well if
> it's a concern) and libavutil/x86/asm.h (only issue here is that I don't
> like duplicating it).
> Nothing else is required.

I missed that, did that change recently?

> I haven't tested the last release, and I don't know if only
> requiring these two headers I mentioned is good enough,
> but I would say it doesn't require an internal copy anymore.

Well, if it was really only two (internal!) headers that it takes, why
doesn't mplayer embed them just like mplayer2 and mpv, and just ditch
the svn:external equivalent for git mechanism? This needs to be
disabled when packaging it for use with a system-provided libavcodec
anyways. I guess the reason is that you still prefer to have it
compile against the very latest tip of ffmpeg, which again, is not the
typical configuration when integrating it into Debian. mplayer
competitors mplayer2/mpv do not seem to be this demanding.

Nevertheless, if what you say is true, then current mplayer should be
indeed rather easy to compile against any copy of libavcodec.

> I even fixed configure so that if you have only those two files
> in ffmpeg/... it will default to compiling against a system FFmpeg.
> Making a new release is something that would be good to do anyway.
> _However_ none of this fixes the FFmpeg vs. Libav issues...

Are they critical for Debian?

I personally don't think so, because I don't consider the missing
functionality that important. If it was, then it could be fixed if
there was enough good will. However, the political pressure and the
constant nagging from both developers and spectators result in a very
aggressive and negative atmosphere, and thus has diminished my
motivation to continue working on the package significantly. I mean,
even you as one of last very active mplayer developers use terms such
as "cripple" to induce political pressure towards FFmpeg.

>> > Now, deb-multimedia.org provides it anyway so it won't leave people
>> > completely stranded, but I wonder if maybe there was a way to
>> > somehow point people there when they try something like
>> > "apt-get install mencoder"?
>>
>> I disagree that deb-multimedia.org is actually helping here. I would
>> rather recommend people that want to use mencoder on Debian to just
>> follow upstream's recommendation: compile it yourself, and statically
>> link against its internal copy of libavcodec.
>
> This is kind of messy on non-developer machines where it involves
> installing compilers an lots of -dev packages, plus not knowing which
> are needed (I suspect the debian packaging scripts inside the MPlayer
> source are thoroughly broken at this point, though I have not tried).

So what? Juts give users a list of packages to install on a wiki page
and improve mplayer's configure script to detect missing packages and
provide better diagnostics, and everyone benefits (including potential
future packagers).

>> > I can see why you might have some concerns with that, but it would
>> > seem like a kind of user-friendly solution to me that doesn't
>> > require much effort from anyone...
>>
>> I don't share this understanding of "user-friendly". (cf.
>> https://wiki.debian.org/DebianMultimedia/FAQ#A_recent_upgrade_of_ffmpeg.2Flibav-related_library_packages_.28e.g._libavcodec.29_has_broken_related_software_.28e.g._Totem.2C_MPlayer.2C_VLC.2C_Xine.29)
>
> This is too light on details to know what was going on.

I don't think users need to know the political background behind all
of this. Since we adopted that policy and explanation, the number of
bug reports of applications that link against libavcodec with crashes
that stem from libraries that interfere here significantly decreased.

-- 
regards,
    Reinhard