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
<leandronu...@safernet.org.br> and Filipe Lautert <fil...@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
embedding).
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
snippet:
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
installed.
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
here):
----- Forwarded message from Hongli Lai <hon...@phusion.nl> -----
Sender: Hongli Lai <hongli...@gmail.com>
From: Hongli Lai <hon...@phusion.nl>
Subject: Re: Boost bundling
Date: Thu, 05 Mar 2009 10:06:44 +0100
To: mi...@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.
Regards,
Hongli Lai
--
Phusion | The Computer Science Company
Web: http://www.phusion.nl/
E-mail: i...@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
signature.asc
Description: Digital signature
