Bug#395252: ignore bug 395252 'mplayer embeds ffmpeg' for lenny

Reinhard Tartler siretart at debian.org
Wed Jun 18 14:24:18 UTC 2008


Pierre Habouzit <madcoder at debian.org> writes:

> On Wed, Jun 18, 2008 at 12:25:33PM +0000, A Mennucc wrote:
>> I fix all bugs that can reasonably be fixed. When ffmpeg in Debian
>> was too obsolete to link to mplayer, there was nothing I could do.
>> 
>> Since 2006, many things happened; for example, in
>> http://bugs.debian.org/403330 I asked for a new version of ffmpeg, but
>> 403330 was closed by the version 0.cvs20070307 that became
>> rapidly obsolete wrt mplayer 1.0~rc2
>
>   Hint: ffmpeg in Debian is team maintained.

Indeed, and any help is more than welcome on this point.

As for the current discussion "mplayer embedding an copy of ffmpeg", I'd
like to express an idea I had proposed previously with A Mennucc and
Sam. I proposed to turn the table:

Since mplayer includes an exact copy of ffmpeg by using an 'svn:external'
on the ffmpeg svn, it makes sense to build shared library packages out
of that source. This way mplayer could even link statically against
ffmpeg (which is recommended by upstream btw) without having to go into
the code duplication argument. In case of an security issue in ffmpeg,
one would need to touch the mplayer source package in any case. The rest of
debian packages using ffmpeg would then link against the shared version
of mplayer.

This has of course serious drawbacks:

 - the complexity of the mplayer package increases in complexity. The
   package needs to be extended with multiple build runs, one for the
   mplayer build, and then one (or even more times) for ffmpeg builds in
   several variants.

 - mplayer doesn't release that often. It might be very well possible
   that other packages would require a newer verison of ffmpeg that is
   provided by the last mplayer release.

The first point probably rules out the implementation of this idea for
lenny. I feel it is to late for that, but I'm neither part of the
release team nor involved in mplayer maintenance, so YMMV.

For the second point I see the following approaches:

 1a. update mplayer to a later svn snapshot.

 1b. keep the mplayer version but update the ffmpeg copy from svn

 1c. keep mplayer and mplayer, but include the diff to the newer svn
     version of ffmpeg.

 2. keep the ffmpeg package but providing updated version of the
    library.

The second approach means of course code duplication and we should avoid
that if we can. I imagine an RC bug preventing propagation to testing of
the package, or keeping that package in experimental only. Having such a
package available would allow experimenting and testing with a newer
ffmpeg copy and help for consideration of approaches 1a to 1c.

A, if you want to work on that, let's discuss this on the pkg-multimedia
list, that is CC'ed with this email.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4



More information about the pkg-multimedia-maintainers mailing list