Demoting ffmpeg and rdepends to multiverse

On Do, 2005-11-03 at 14:39 +0100, Sam Hocevar wrote:
> On Thu, Nov 03, 2005, Sebastian Dröge wrote:
> 
> > >    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.
> 
>    "plugin" means it can be disabled and has no other effect on the
> package than the missing functionality.
> 
> > >    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.
> 
>    Haha. Have fun.
> 
> > 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.
> 
>    And everything will be uninstallable until all packages are rebuilt,
> which could take ages if other transistions are occurring. To detect
> what needs to be rebuilt when you upload a new version you don't need to
> break all FFmpeg-using packages, you just need apt-rbdepends[1].
> 
>    Waiting for everything to break *in* the distribution is not the
> proper way to do things. If you really care about it, you need to put
> all FFmpeg and FFmpeg-using packages in a staging area. And that can be
> done whether shared or static libraries are shipped. And what is good
> with using static libraries in this case of rapidly changing APIs/ABIs
> is that a source package stuck into another transition and that cannot
> be rebuilt does not prevent all the other packages from being rebuilt.
> 
> > >    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 ;)
> 
>    So you no longer claim it is a problem, you just say it will be
> easier to spot. Well, I disagree. See above.
> 
> > >    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?)
> 
>    Oh please. Don't tell me no one knows how to remove a few files they
> don't like from a tarball.

Sure, can be done... I'll leave this to crimsun as he knows more about
vlc than I do

Judging from your and Matthew's comments I think we should leave
everything as it is, move already in multiverse parts of ffmpeg back to
universe and wait for ffmpeg to release something stable.

And in the future when there's something with vlc or ffmpeg I'll talk to
you directly first ;)

Only one last question... quote by Matthew...
> Now, what would be helpful is a clear and concise list of which parts
> of 
> ffmpeg are free and which are awkwardly patent encumbered, and
> whether 
> it's practical to split the two of them out.

Do you have a list of all parts of ffmpeg and whether they're really
free or patent covered?

Bye

PS: sorry for all the hassle
-------------- 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/89f3afed/attachment.pgp