[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#488753: (forw) Re: Boost bundling

In an effort to try and determine where the situation with Passenger in
Debian is stalled, I went on a small adventure to figure out where
things are. What follows is the details of the current situation, as
well as a helpful explanation from the Passenger folks. I intend to
respond to that message when I can, but first I wanted to get the
current state of things loaded up into this bug report, so others can
see where things are at.

First I found that Passenger/mod_rails had been uploaded to NEW[0] some
four months ago by Leandro Nunes dos Santos
<leandronunes@safernet.org.br> and Filipe Lautert <filipe@debian.org>.

However, it had not been accepted by the FTP masters, and as such it was
not part of the archive yet. Typically when there is a delay such as
this in accepting the package into the archive there is some problem,
either legal/licensing or technical that is keeping the package from
being accepted. I contacted a member of the FTP team to ask what the
hold-up was and was told the reason is because passenger has an embedded
copy of boost and the FTP team has asked the maintainer at least twice
about it and have received no reply. 

The embedded code problem is an interesting one, one that I have been
involved in over the years working in on testing-security where we've
been forced to track embedded code copies in Debian[1] so that we could
have a chance to deal with security issues in embedded code copies. (A
prominently horrible example is the xpdf code-base which was at one time
embedded in more than 10 different source packages in Sarge, this was
reduced in Etch significantly thanks to the xpdf library fork called
poppler which packages were encouraged to link against, instead of

As a result of these issues causing significant number of hours to
track, update and manage, with many clever technical solutions developed
to do things like use the clamav signature mechanisms to scan the entire
archive, etc. Eventually the Debian project saw fit to adopt a policy[2]
with specific language about embedded "convenience copies" of code
(section 4.13). And this is where Passenger is currently stuck.

I took a little bit of time the other day to try and figure out why
Passenger embedded Boost and could not find much rationale online, until
I found an older blog post[3] about the 1.0.2 release that contains this

  Fixed conflicts with system-provided Boost library

    Passenger makes use of the Boost C++ library. Its sources are
    included into the Passenger sources. But if the system already has a
    different Boost version installed, then the two Boost libraries
    would conflict with each other, and Passenger would fail to
    install. We’ve made sure that this doesn’t happen: now, installation
    will succeed even if there’s already another Boost version

This is a good first effort, however I believe that this solution
doesn't get at the root of the problem and instead makes one of the
symptoms go away instead of solving the problem. So I posted to the
comments section of the blog asking for more details, and describing the
issue around embedding copies of other code, and then received the
following response in email (which I have obtained permission to forward

----- Forwarded message from Hongli Lai <hongli@phusion.nl> -----

Sender: Hongli Lai <honglilai@gmail.com>
From: Hongli Lai <hongli@phusion.nl>
Subject: Re: Boost bundling
Date: Thu, 05 Mar 2009 10:06:44 +0100
To: micah@debian.org

Hi Micah,

I saw your reply to my blog about making Boost a build dependency, but I'm 
afraid your arguments do not hold in our case:

- The best argument for wanting to depend on Boost dynamically, is to make 
it easier to solve security problems. However, upgrading the Boost library 
will only partially fix security problems. That's because most Boost code 
live in C++ header files, which get inlined directly by the compiler into 
the executable. If a security flaw was found in a header then you'd have to 
recompile the executable that uses Boost even if Boost is a shared library.

- Most people don't have Boost installed, or don't have the right version 
of Boost installed. By far and large, most of our users are _not_ Debian 
users, and installing Boost is a huge huge pain for 80% of our user base. 
By _not_ bundling Boost we'll alienate most of our users. I have a 
different software program which does not bundle Boost, and the #1 support 
question by users is related to installing Boost.

Even Debian users will have a difficult time. We depend on a very specific 
version of Boost, one that hasn't been packaged by Debian yet.

I don't think that telling our Debian users "what? don't have the right  
version of Boost installed? then wait x months/years until Debian has  
packaged it, then upgrade your distro" is an acceptable answer to our  
users, don't you agree?

The Fedora guys have tried to patch Phusion Passenger to get rid of the  
Boost bundling, but after they're done they found out that Fedora ships  
the wrong version of Boost, putting them back at square 1.

- We have made all kinds of modifications to Boost, which are specific  
Phusion Passenger. If you try to compile Phusion Passenger against a stock 
Boost it wouldn't succeed

If you have more questions I'd be glad to answer them. But please  
understand that we bundled Boost for good reasons, not because we like  
imitating Windows.

Hongli Lai
Phusion | The Computer Science Company

Web: http://www.phusion.nl/
E-mail: info@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

----- End forwarded message -----

0. http://ftp-master.debian.org/new/passenger_2.0.3-1.html
1. http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file&rev=0&sc=0
2. http://www.debian.org/doc/debian-policy/ch-source.html

Attachment: signature.asc
Description: Digital signature

Reply to: