Packaging rack-based applications for Fedora

Tue Feb 15 14:44:05 UTC 2011

Dne 15.2.2011 14:34, Mamoru Tasaka napsal(a):
> 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.

1) The best for the application is if it runs in isolation, therefore 
there were invented bundler and isolate.
2) For running of application, it is sufficient to load the application 
dependencies using: RUBYOPT="Ipath/to/my/dependency1 
Ipath/to/some/gem/wherever/it/is" As you see, by specifying the 
explictit RUBYOPT, there are not rubygems required at all (speaking 
about R1.8, for R1.9 it is a bit different). The dependencies are 
maintained by RPM, therefore it is safe to use it on Fedora. So you 
there is no fallback. And the same apply for rubygems. I assume you are 
already familiar with these posts:

http://tomayko.com/writings/require-rubygems-antipattern
http://yehudakatz.com/2009/07/24/rubygems-good-practice/

>>>> 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)?

I don't have benchmark.

The delay of application start might by significant. Also, if you are 
using rails 3 in development mode, they are reloading everything for 
each request. Another example where you feel such penalty is when you 
are using autotest for example.

>>>> 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".

It starts to look, that it would make the things easier for Fedora if 
the upstream stop providing gem and starts providing tar.gz instead. But 
this does not make a sense at all.

>> 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.
>

I am asking for standardization of packaging Ruby applications, to 
prevent future confusion. And honestly, Rails and Sinatra applications 
are simply applications.

>>>> 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_package_information
> 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.

Yes, they might be invalid, but one can learn even from other's errors.

>> 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).

Easier doesn't mean correct. We should distinguish between. As FHS 
states: The /usr/share hierarchy is for all read-only architecture 
independent data files. Much of this data originally lived in /usr (man, 
doc) or /usr/lib (dict, terminfo, zoneinfo).

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA

>>>> 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.

Yes, you break it anyway when you installing gem which has executable 
for example. Many times there are installed tests and rake files for 
gems which does not include them originally. Again its a breakage. May 
be I could find another examples.

Take the gem just as an archive, nothing else. It happens many times 
that upstream doesn't have ideal folder structure.

Vit