Vít Ondruch wrote, at 02/15/2011 09:26 PM +9:00:
>> 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.
But even if you put everything to %_datadir, if the required file is not found
ruby will search it under loadpath, and if it is not found ruby will complain
"it was not found". Unless you specify first all loadpaths (including files
provided
by other pkgs), your method will fail anyway.
>> 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.
And you have some benchmark? And the delay happens at any time (i.e. not
only when the application launches)?
>> 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.
I am saying that if the upstream are using rubygems, let's use rubygems as
the upstream does. It is again simple. Again what I am saying is that "let's make
it
simple".
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 .
Sorry but actually I am very tired of the discussion of "as this is
application"
or "as this is a module" or so. This is actually one of the annoyance I
frequently
meet during review requests (this never-ending discussion happens not only on
ruby related pkgs). Judgment of this type differs between each reviewer
and unless we set an "apparent" criterion this type of distinction.
And please keep in mind that reviewers are not always familiar with ruby.
>> 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...
Again don't think of "Debian". Debian has confusing packaging schemas on
many points and "as Debian does" is not valid on Fedora in many ways.
At second, it conforms not only Debian, but also FHS
Putting everyting under /usr/lib is easier way to follow FHS, actually....
(apart from /usr/bin or so).
>> 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.
What is complicated is that you break the file structure what "gem install"
does and add some
wrapper script, while it is not actually needed.
Regards,
Mamoru