Packaging rack-based applications for Fedora

Vít Ondruch vondruch at redhat.com
Tue Feb 15 10:08:26 UTC 2011


Dne 10.2.2011 18:33, David Lutterkort napsal(a):
> On Thu, 2011-02-10 at 17:12 +0100, Michal Fojtik wrote:
>> * Where should be these application installed?
>>
>> My preference is to install them inside /usr/lib or /usr/share directory.
> I wouldn't do that - it's only extra work during packaging, for no added
> benefit

Well I would say that we are speaking about first Sinatra application 
which is going to Fedora (at least I am not aware of any other). So if 
we don't do it right for the first time, then we will create dangerous 
precedence. Actually, the installation into /usr/share is quite 
straightforward. Here are steps how to proceed:

1) Lets assume the application is packaged as a gem for convenience
2) Do gem install as usually.
3) Copy the %{buildroot}%{geminstdir} into /usr/share (the version 
should be probably omitted?)
4) Instead of /bin/appname, which is usually provided by rubygems should 
be used script which is static. Please see attached deltacloudd-orig 
(provided by rubygems) and its modified version in deltacloudd file.

The RDoc documentation which would be available from Gem should be 
replaced by its Man alternative, as it should be for every application 
(and this is commonly not true for executable gems).

Pros:
1) Ruby load path pollution is avoided.
1a) Since every gem is automatically added into load path, there might 
be unnecessary conflicts. For example the deltacloud-core has some 
Sinatra extension in lib/sinatra/ folder and these extension can 
conflict with installed gems.
1b) Every gem added to Ruby slows down ruby require performance. 
Although it looks to be negligible penalty, it is unnecessary penalty at 
least.

2) Ruby application has nothing to do with RubyGems. If they are 
provided as a gem, it just for convenience, but it does not mean anything.

3) This approach follows the way how the Redmine is packaged in Debian 
for example.

Cons:
1) May be slightly more work for packager? But work which is done once.


Vit


More information about the ruby-sig mailing list