Packaging rack-based applications for Fedora

[Mamoru Tasaka]

Vít Ondruch wrote, at 02/15/2011 11:44 PM +9:00:
>> 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/

You are just saying that it can be done without rubygems... With rubygems
if we set "gem foo" in advance there is no fallback.

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

If you see signicicant delay, teaching the upstream not to use gem, or
modifying rubygems is much preferable, for people not only on Fedora
but also people not using Fedora. Not discussing with the upstream does
not help.
I just think that if the upstream uses rubygems, there is
some reason (maybe just because it is easier to develop with gem).

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

Note that if some "significant" packaging change happens submitting re-review request
is preferred, even if not changing the srpm name. It is quite imaginable that
switching gem to tar.gz may mean some additional change in packaging.


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

So what is "application" or not is not obvious, especially for reviewers
not familiar with ruby, and this happens also in non-ruby packages. Unless
you have a "clear" criterion about how we can judge what is "application" or
not (which is apparent for all reviewers), this just causes unneeded confusion.

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

Again current packaging does not break FHS.
- Note that with introducing ruby 1.9.x on Fedora, kanarip already proposed to
   change the structure of installation directory, such as moving arch-independent
   files to %_datadir, and others.
With still using ruby 1.8.x, I see no need for changing current directory structure
- By the way I think we should try to import ruby 1.9 on Fedora 16.

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

Path for installing directory can be speficied with --bindir, actually,
so there is no need for "mv %{buildroot}%{gemdir}/bin/* %{buildroot}/%{_bindir}"
craft in fact. And if you install gem as root without specifying --installdir,
scripts are installed under %_bindir, so there is no breakage, sorry.

> Take the gem just as an archive, nothing else. It happens many times
> that upstream doesn't have ideal folder structure.
While we use rpm, "gem" command actually offers some useful way to show
the status of installed gem archive. So in that gem archives have nice
relation with "gem" command, gem is not just an archive.

>
> Vit
> _______________________________________________

Again please show us the point current packaging way based on rubygems
is _definitely_ unsuitable for packages you are now trying to import
(anyway I appreciate your contribution, of course).

Regards,
Mamoru