Demoting ffmpeg and rdepends to multiverse

On Wed, Nov 02, 2005, Sebastian Dröge wrote:

> In the case of vlc it currently uses a bundled ffmpeg version as
> libpostproc-dev is currently already in multiverse and vlc can't build-
> depend on it because of that. Demoting it to multiverse will solve this
> obviously ;)

   Which version of VLC are you packaging? Official VLC releases have
never shipped a bundled FFmpeg version, and special tarballs for
distributions (such as the one used in Debian) have not shipped FFmpeg
for almost a year.

> This is for the following reason:
> We currently use the ffmpeg from Debian but this is somewhat stripped
> from "funny" formats (AAC for example, libfaad2 is in multiverse).

   This does not sound like a valid reason as far as VLC is concerned,
because VLC does not use FFmpeg's AAC support but has its own separate
plugin.

> When ffmpeg is in multiverse we could use Marillat's version [1] of
> ffmpeg which supports these formats. In fact even our version contains
> support for some suspect formats (mpeg video encoding as an example).

   Marillat's utter ignorance of APIs, of transitions, of compatibility,
of ABIs, of library SONAMEs and even of copyright cannot be stressed
enough. You should be very careful if you plan to use his broken
packages.

> Using Marillat's version would give us also another advantage (which
> could be added to our current package too obviously):
> 
> Our current ffmpeg package ships only -dev packages for libavcodec
> and libpostproc. These contain the static .a archives and no package
> with shared .so libraries is available from our ffmpeg package. This
> yields to the following problem: when updating ffmpeg all packages using
> it need to be recompiled to use the advantages of the updated ffmpeg

   This is a totally spurious argument. FFmpeg is not compatible with
itself across releases and as long as its API and ABI are not stable,
the only way to ensure that an FFmpeg-using binary will still work after
an upgrade (either of the binary or of FFmpeg's libraries) is to rebuild
it.

   If you are going to distribute shared libraries, you will have to
either change the SONAME on each new release (and become incompatible
with Marillat's packages, who AFAIK keep the same SONAME), or organise
transitions for FFmpeg-using packages each time you do a new upload,
probably with extremely strict shlib rules.

   In the end, you will see that when updating FFmpeg, all packages
using it will need to be rebuilt to benefit from it. Which is exactly
the problem you try to ascribe to the shipping of static libraries.

> and
> (more important) _every_ binary which links against libavcodec gets 2-3
> mb bigger! for example for transcode this makes a real difference as it
> contains many binaries linking against libavcodec. The compressed size
> of the binary is ~14 MB instead of ~2 MB, the installed size is ~40 MB
> instead of ~5 MB.

   This is indeed a problem. I suggest bearing with it until the FFmpeg
API becomes stable.

   If the binary size really becomes intolerable, I suggest shipping a
shared version of libavcodec et al. with the transcode package, renamed
to /usr/lib/libavcodec-transcode.so.X, that you can build from the
objects in the libavcodec-dev package (extract the objects from the
_pic.a lib and build them into a shared object).

> Using Marillat's version also helps in this case.
> Shipping only static libraries is also generally discouraged [2]

   And I quote your own reference: "Unstable ABI is one reason to
provide static libraries for".

> Do you have any comments on this or can we do it right now?

   I see no real reason for putting VLC in multiverse. If you need
help fixing some technical problems (such as my suggestion for the
transcode package), I'd be happy to help. I am upstream for VLC as well
as the Debian maintainer for both VLC and FFmpeg so I have quite some
experience with the whole stuff.

Regards,
-- 
Sam.