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