Packaging rack-based applications for Fedora

[Mamoru Tasaka]

Well,

Vít Ondruch wrote, at 02/15/2011 07:08 PM +9:00:
> 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.
Um? "gem 'foo', '>= ver'" is actually intended to specify load path and
its order, and to avoid such conflict. You can check this by actually checking
the load path.

> 1b) Every gem added to Ruby slows down ruby require performance.
> Although it looks to be negligible penalty, it is unnecessary penalty at
> least.
I don't think this is not the supporting reason for your way of
packaging.

> 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.
But there is no need we should avoid using rubygems... Or you have strong
reason we mustn't install rubygems?

> 3) This approach follows the way how the Redmine is packaged in Debian
> for example.
Please don't think of Debian's way.

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

I can't see the benefit of such "complicated" way of packaging. Let's keep
it simple unless unavoidable.
- By the way, I can't see your attached spec or srpm.

Regards,
Mamoru