Bug#732159: Should this package be removed?

[Reinhard Tartler]

On Sun, Feb 16, 2014 at 12:58 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de> wrote:
> On Sun, Feb 16, 2014 at 12:16:59PM -0500, Reinhard Tartler wrote:

>> In lack of any *constructive* comments about this, I would say yes,
>> let's remove them.
>
> 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".

> 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.

> 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).

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. This was only acceptable because I made sure
that its internal copy is only used at build-time, allowing mplayer to
access internal functionality that is not part of the public API. This
makes maintaining mplayer in Debian much more challenging, and
basically means that mplayer and libav always need to be updated in
lockstep. It is true that for quite some time I used my mplayer svn
commit privileges to make it possible to use libav instead of ffmpeg
as internal copy. I stopped doing this work, mainly because I felt
that these kind of work is not welcome inside mplayer. BTW, this is
the main reason why I cannot support mplayer/mencoder anymore in
Debian.

Both mplayer2 and mpv work just fine without any internal copy of
libavcodec and friends.

BTW, as soon as someone appears that actually manages to maintain the
mplayer/mencoder package, we can always re-introduce the package to
Debian. Actually, I would be very interested in that, but not before
there was some mplayer release that stopped requiring an internal copy
of libav* - These days, I'm unable to cope with the amount of work
that I had to invest to keep mplayer up-to-date in Debian so far,
sorry.

> Though I agree that there is little point in keeping the outdated
> rc4 version.
> But one more point: I am not sure all programs using mencoder
> will have it as a dependency correctly.

That would be very unfortunate. Please file bugs if you find packages
that lack this dependency.

> For example flvtool (exists only in stable though it seems) should
> be using mencoder for some tasks but does not list it as a
> dependency.

We are discussing removal from unstable here, not stable.

> 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.

> 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)


-- 
regards,
    Reinhard