Providing non-stripped ffmpeg libraries

[Andres Mejia]

On Monday 25 May 2009 01:32:27 Reinhard Tartler wrote:
> Andres Mejia <mcitadel at gmail.com> writes:
> > 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.
>
> exactly!
>
> > 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.
>
> What makes you think so? From my private irc queries, Ganneff has
> indicated to me exactly the opposite. Moreover, public requests like
> #522373 are actively being ignored.

Well, that's the impression I had from that email I mentioned. I really wish 
these irc channels had public logs. It's mainly the reason I prefer the mailing 
lists.

Anyway, what were the reasons for opposition? And who is Ganneff by the way?

> > 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.
>
> We could of course just upload them, but I fear they will rot in new and
> Ganneff/mhy will refuse to leave any comment on that.
>
> > 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.
>
> yes, that was the original idea with renaming the source package in main
> to 'ffmpeg-debian'. At that time, ffmpeg upstream were really angry
> about the situation in debian. Renaming seemed to me a good idea for
> indicating to both upstream and users that we are shipping something
> that is based on, but functionally different to what upstream
> provides. Nowadays, I think they are in some ways even respecting us,
> just note how fast your patches have been applied! (It wasn't the case
> when I started working on the package)
>
> > 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.
>
> this would cause different binary packages with the same name but
> different versions in the archive, right?

This I realized earlier is not possible, according to Debian policy 3.1.

So the libraries in non-free would have to be named lib*-unstripped.

> > 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.
>
> Technically yes, but are you really sure that dak plus all archive tools
> that the archive administrators use can cope with this?
>
> Also keep in mind that ubuntu already ships the unstripped variants, and
> the users are rather happy with that. I really doubt that this will work
> over there.
>
> > 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.
>
> this can also be achieved with adding a suffix to the debian
> revision.  Your 2nd method also includes having 2 binary packages with
> the same name in the archive.
>
> > 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
>
> The idea with the shlibs trick came originally from Loic Minier, I've
> implemented it then. I believe it was early 2008, but I have to search
> my local archives. I have a vague memory that we didn't consider your
> idea at that time, but TBH, I don't think this is technically possible
> with the neither the debian nor the ubuntu archive.

Right, the package names have to be unique.

In this case, we could still do the shlib trick, but with packages that will 
depend on the ffmpeg libraries, have the unstripped libraries come first before 
the stripped ones for the resulting dependencies.

For example:
libavcodec-unstripped-52 | libavcodec52

In this way, the unstripped libs resolve first for those users who activate the 
non-free component in their sources.list.

This of course assumes that an unstripped version of ffmpeg makes it into Debian 
in the first place. I really would like to know what the reasons are for not 
accepting ffmpeg unstripped in non-free.

-- 
Regards,
Andres