Providing non-stripped ffmpeg libraries

Andres Mejia mcitadel at gmail.com
Sat May 23 19:48:37 UTC 2009


Hi all,

Just want to propose some alternative to providing unstripped ffmpeg libraries 
other than having users build it from the git repo.

So right now, ffmpeg-debian is the source package that builds the current 
libraries, -dev packages, doc package, and the other packages that are part of 
ffmpeg. Also right now, we all know that both the source package and the 
libraries are crippled in the sense that these packages do not provide certain 
encoders that are important to a lot of users.

I would like to bring back the issue of having an ffmpeg package in non-free [1]. 
To me, it seems ftp-master is at least willing to consider providing an 
unmodified form of ffmpeg in non-free with the various mpeg and h26* encoders 
enabled. Seeing how we were trying to provide unstripped library packages, I 
propose that we provide these unstripped library packages in the non-free 
component of the archive with some changes.

I propose the name of the source package be left as 'ffmpeg' and that the source 
be unmodified. In this way, we can assure users that this is an unmodified version 
of the ffmpeg source as is checked out from SVN.

Second issue is the binary packages that are provided. We can have the ffmpeg 
source package just build the unstripped libraries just as it was being done 
before.

With the unstripped libraries, I propose that we do not call the libraries lib*-
unstripped, but instead, keep them named exactly as their counterparts from the 
ffmpeg-debian source package (i.e. libavcodec52, libavformat52, etc.). In this 
way, users who activate the non-free component would have the proper library 
automatically installed for them.

With the issue of keeping the name of the binary packages for the library the 
same, this is assuming some things. For one, the main packages in the archive 
are seperated from the non-free package in the archive anyway. That is, they 
reside in their own directory (pool/main/f/ffmpeg-debian, pool/non-free/f/ffmpeg) 
so there will never be any name conflicts with the library packages. Also, the 
main and non-free component have their own 'Packages' file, so even though there 
would be two binary packages with the same name for each ffmpeg library in the 
archive, the location of the library packages would be different according to the 
'Filename' field of each package inside each of the 'Packages' file for either the 
main or non-free component.

So basically this all assumes a program such as apt will resolve what package to 
install from a particular component in the same way as it resolves what package 
to install from a particular url, or a particular distribution.

With keeping the name of the libraries the same, there comes the issue of what 
version to use for each package. Here are two ways I propose we could version 
the packages.

One, we keep the version of the packages the same. In this case, it is up to 
users to provide the proper apt-pinning to install the various libraries.

Or two (this is the method I prefer), we keep the version of one package higher 
than the other, through the use of an epoch. In this case, the version of the 
packages in non-free should be the ones with a higher version. This is assuming 
that the majority of users of the ffmpeg library will want to use the unstripped 
libraries. The minority can either not activate the non-free component, or 
provide the proper apt-pinning.

Thoughts?

One more thing, if this has already been proposed somewhere, forgive me for 
making you read such a long email. I could not find any other proposals besides 
the url I provided, and the proposal to have users build from the git repo.

1. http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2007-
December/000671.html

-- 
Regards,
Andres



More information about the pkg-multimedia-maintainers mailing list