Towards a Fedora Ruby appserver

[Mohammed Morsi]

  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