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