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