Dne 15.2.2011 12:35, Mamoru Tasaka napsal(a):
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.
Well, if the required file is not found on loadpath already, it will
fallbacks to rubygems and rubygems will try every gem/lib path to
require the file. So your gem command can't help here.
> 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.
Performance is everytime good reason and should not be overseen.
> 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?
This is not discussion about using/notusing rubygems itself. I am not
suggesting that we should avoid rubygems, while I admit there are also
different solutions which replaces rubygems entirely in some or all
rubygem domains (
http://hellorip.com/,
http://gembundler.com/,
https://github.com/jbarnette/isolate).
I am just trying to point out that not everything, what available as
rubygem, has to be necessarily present as rubygem in scope of Fedora,
not even mention FHS.
If we have application Foo, it should be placed under /usr/lib,
/usr/lib64, /usr/share and not under /usr/lib/ruby/gems/1.8/gems/foo .
> 3) This approach follows the way how the Redmine is packaged in
Debian
> for example.
Please don't think of Debian's way.
At first, if you read guidelines, inspiration from other distributions
is encouraged:
http://fedoraproject.org/wiki/How_to_create_an_RPM_package#Reuse_existing...
At second, it conforms not only Debian, but also FHS
> 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.
This thread started because I am doing review for this package:
https://bugzilla.redhat.com/show_bug.cgi?id=674060
This approach is equivalently complicated to installing the gem in %prep
section and later copying the folder structure in to %{buildroot} in
%install step. So I hesitate to speak about complication at all.
Btw I forgot to attach the deltacloudd and deltacloudd.orig files
mentioned in previous mail :/
Vit