Bug#456165: Details from Handbrake as to why it is statically linked to libraries

[Reinhard Tartler]

On Wed, Sep 12, 2012 at 1:45 PM, Alex Brooks <askoorb+debian at gmail.com> wrote:
> Hello,
>
> I'm new to the Debian bugs system, so please excuse me if I break etiquette.
No, you're doing perfectly fine!

> I'm really looking forward to Handbrake being available in the main
> repositories, but I thought that the packagers need to be aware of
> some information that the Handbrake devs have written about why they
> statically link to libraries.
>
> First, from their development FAQ (https://trac.handbrake.fr/wiki/SupportFAQ):
>
>>Why doesn't HandBrake use my system libraries?
>>HandBrake requires a lot of control over the specific versions of 3rd party libraries it utilizes. To make sure everything is to its specifications, it downloads and builds most of its dependencies and statically links them, all without touching your system libraries."
>

That's an perfectly understandable reasoning from an upstream
perspective. The problem is that this conflicts with the requirements
of a distribution of the size of Debian. Here, shipping the same piece
of software in different versions embedded in other packages makes the
life of package maintainers, release managers, archive administrators
and the security team unnecessarily hard. Therefore, we cannot accept
this and need patch the software to work with the system provided
libraries.


> and
>
>>"Why can't I build HandBrake? x264 fails to compile and then libhb does too.
>>You need to build and install yasm for x264 to use cpu acceleration."

Debian does already ship a working copy of x264. Handbrake should just use it.

> Also, in the source, there is a file called README.debian.  I've
> pasted the contents of the file at the bottom of this message.  It's
> very informative.
>
> Thanks, and good luck with getting Handbrake packaged up!
>
> Alex Brooks
>
> ======================
>
> handbrake for Debian
> --------------------
>
> HandBrake bundles its own copies of ffmpeg and related media libraries. This is
> an upstream decision that the Ubuntu maintainers will respect.

Yes, that may be fine for ubuntu, and might be fine for
debian/experimental. It is certainly unacceptable for a debian stable
release. Having said this, I'd be OK to have embedded libraries in an
upload to experimental.

> This is done by running contrib/getcontrib.sh which wgets each library from
> HandBrake's website.

Yeah, the autobuilders in both debian and ubuntu do not have access to
the internet at compilation time. Therefore, the parts of the build
scripts that download stuff need to be disabled and all sources need
to be available in the source package.

>
> Upstream has asked us to do this because they have modified their libraries to
> address the finickiness of the platforms that they support, along with
> prerelease patches that add support for advanced HandBrake functionality such as
> surround-sound downmixing.

Again, that's understandable, but more a workaround than a solution.

> HandBrake then statically links against these libraries, and they are not
> installed to the system so it doesn't interfere with other parts of the system.
> Different or older versions of these packages are included in the Ubuntu
> distribution already, and have passed our guidelines for Multiverse inclusion.

As indicated above, this static linking is what makes packaging
handbrake challenging.

>
> === Detailed Breakdown of Bundled Libraries and Reasons ===
>
> a52dec - 0.7.4
> patch to allow downmix to dolby prologic ii

Can be included in the distro package

> faad2 2.6.1
> patch to configure.ac so it will build with libtool 2.2.x

Not necessary when using the system copy

>
> ffmpeg svn 15462
> patch for building on beos
> patch that adds aac-latm codec
> patch fixes memory leak provoked by h264 streams with lots of errors
> patch for cygwin
> patch for solaris

debian does not support beos, cygwin or solaris, so those patches are
irrelevant. Debian's libavcodec does support aac-latm already. I'm not
sure about the memory leak fix, but that fix should be fixed upstream
in any case.

> libdca svn 81
> newer than released version

We can update the system copy of the library, no problem here.

> libdvdread 0.9.7
> patch for os x, changes path to dvdcss
> patch for cygwin, configure fixes

all of those do not affect debian.

> faac
> patch for cygwin configure

please see https://bugs.launchpad.net/ubuntu/+source/faac/+bug/374900

My understanding is that including faac in GPL'ed binaries as
Handbrake does results in unredistributable binaries.

> lame version 3.98

What about it?

> libmp4v2 svn 45
> project was stagnant. using a fork that has picked up development

So?

> libmkv 0.6.3
>
> mpeg2dec 0.5.1
>
> libogg 1.1.3
>
> libsamplerate 0.1.4
>
> libvorbis aotuv fork b5
>
> libtheora 1.0
>
> libx264 git 1028
> patch for cygwin configure
> patch for solaris build scripts
> patch to allow forcing an IDR frame
>
> xvidcore 1.1.3
> patch for os x configure
> patch for cygwin configure
> patch configure to recognize nasm 2.0

All of those are no problem to not use the system provided version.


-- 
regards,
    Reinhard