Demoting ffmpeg and rdepends to multiverse

On Do, 2005-11-03 at 13:25 +0100, Sam Hocevar wrote:
> 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.

No idea, crimsun?

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

Which is another reason why vlc needs to go to multiverse. It ships the
complete faad2 sourcetree and faad2 is currently in multiverse.

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

Yes, I already noticed this with other packages by him. But in the case
of ffmpeg it should be fine, the only thing I don't trust him is for
incompatible API versions but I'll verify if the API changed with every
new version.

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

Yes rebuilding is needed in all depending packages when updating ffmpeg.
But when using shared libraries (with shlibs (>= currentversion) (<<
newversion)) breakages will show up imediatly as everything needs a
rebuild to be installable. This way broken packages must be handled
early and can't be deferred like now which will yield to unbuildable
packages in releases.

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

see above answer ;)

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

Thanks for your help :)
But VLC has to be in multiverse, no matter what happens to ffmpeg
because of the included faad2 (or is this only the case with our
package?)

For ffmpeg I'll think about your and matthew's comments but from what
I've read I think we'll probably better stay with the current solution
then... and move all ffmpeg packages which are already in multiverse
back to universe.
Doing my first suggestions seems to be like a switch from plague to
cholera now so we better stay with the current solution for the near
future.

and your transcode suggestion seems to be the way to go for the near
future... I'll try to get it done this weekend.

thanks again, I'm happy that I got more reactions to this mail than to
the other 3 months ago.

(for the issue of ffmpeg beeing possibly non-free I only know of the
discussions about the ffmpeg package in debian on their mailinglist)

Bye
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.ubuntu.com/archives/ubuntu-devel/attachments/20051103/087c7a33/attachment-0001.pgp