On 10/22/2010 09:56 PM, Gaveen Prabhasara wrote:
<snip>
> Ruby webserver
> ==============
>
> Mostly passenger vs. thin vs. unicorn. Passenger has the advantage that
> it can be loaded as a module into httpd, but packaging it has proven
> somewhat interesting.
Phusion team promised that they'd make Passenger 3 more easy to package.
I haven't been able to verify that they've kept the promise. ;) However with
the final release of 3.0 we have another entry to this list; Passenger
Standalone [1]. Given the fact it's uses an Nginx core it might be worth a
look for packaging.
Passenger can't be included in Fedora as is due to legal reasons. If we
want to ship it, we will have to hack it to remove some vendorized
components and call it something else ("Phusion Passenger" is
trademarked, perhaps "modrails" would work though)
https://bugzilla.redhat.com/show_bug.cgi?id=470696
> Plugins
> =======
>
> Mostly an exercise in collecting people's favorite plugins, and making
> sure they are in F15, in the right version.
Here's a wild thought (not original, came up in Twitter discussions). Why
don't we try to work with
rubygems.org to generate (or at least get some
level of integration to) native packages; in our case RPMs? It's bit
ambitious. But it's certainly worth looking into. This could eliminate the
need to use *.gem instead of replying on rubygem-*.rpm
Might be somewhat different that what your talking about but I actually
wrote a tool to do something like this a while back. It sits inbetween
the gemcutter webhook api and rpmbuild, constructing rpms and yum repos
when gems are pushed. I haven't touched it in a while, but might be
worth reviving.
http://github.com/movitto/polisher
http://github.com/movitto/polisher-scripts
-Mo