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

Bug#488753: (forw) Re: Boost bundling


*Mark/FTP Masters team*,

As stated in e-mail below from Hongli Lai (passenger's mainstream), boost library has modifications specific to passenger, so we won't be able to use a "generic" library package.

Is this case, I request that you ACCEPT this package.


thanks for your kindly help on this issue. I've been running out of time lately and was just keeping my other packages in shape, leaving passenger behind.

Best regards to you all,


Micah Anderson wrote:
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

Reply to: