Tags

employment
llc
xrp
redhat
ripple
interfaces
ncurses
ruby
refs
filesystems
retro gaming
raspberry pi
sinatra
3d printing
nethack
gcc
compiler
fedora
virtfs
project
gaming
vim
grep
sed
aikido
philosophy
splix
android
lvm
storage
bitcoin
projects
sig315
miq
db
polisher
meditation
hopex
conferences
omega
simulator
bundler_ext
rubygems
book review
google code in
isitfedoraruby
svn
gsoc
design patters
jsonrpc
rjr
aeolus
ohiolinuxfest
rome
europe
travel
brno
gtk
python
puppet
conference
fudcon
html5
snap
tips
ssh
linux
hardware
libvirt
virtualization
engineering expo
cloud
redmine
plugins
rpm
yum
rake
screencasting
jruby
fosscon
pidgin
gnome-shell
distros
notacon
presentation
rails
deltacloud
apache
qmf
passenger
syrlug
hackerspace
music
massive attack
backups
crypto
vnc
xsd
rxsd
x3d
mercurial
webdev
ovirt
qpid
haikus
poetry
legaleese
jquery
selenium
testing
xpath
git
sshfs
svg
ldap
autotools
pygtk
xmlrpc
slackware

Sep 14 2010 fedora passenger ruby

Phusion Passenger / Fedora Woes

The Phusion Passenger Fedora package submission has been open for nearly two years running. Many various issues have been resolved since the original submission (many thanks to all those involved for their hard work), but there is one last major blocker which is proving to be a headache for this process.

Namely passenger vendorizes the boost thread library. This is done to add some additional features (see the bugzilla issue, I won’t go into details here) but this is unacceptable for Fedora, and thus until it is removed, rubygem-passenger can’t be included. The idea behind this rule is that if a library releases some security or other updates, we manually have to include those in each project that vendorizes it.

As indicated by an upstream developer, passenger should work against the stock boost shipped with Fedora, albeit without some of the additional features. But since the change would be fairly invasive and those features would be removed, they are going to enforce their trademark on “phusion passenger” and insist it be renamed to something else if we make these changes. Of course they are within their legal right to do so though IMHO (and this is my opinion only) this may cause some reluctance to adopt passenger as one of the strongest points pertaining to FOSS is the ability to redistribute code easily with as few barriers as possible.

So this is where we are, should we choose to patch passenger to work against the stock boost, we will have to rename it, else we will not be able to ship passenger at all (without a FESCo exception, which is unlikely for these reasons). Granted while you can still get it via gem, this is not acceptable for all deployment scenarios, and it would be good to have it in Fedora regardless.

This is one of those issues where both sides are correct for their own reasons, and there is no intrinsically right or wrong answer, just different approaches / ideologies. Any thoughts? (looking for solutions acceptable to everyone, no flamewars)