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 version. -- regards, Reinhard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
