On Wed, Sep 12, 2012 at 1:45 PM, Alex Brooks askoorb+deb...@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
