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