Dne 15.2.2011 20:50, Mamoru Tasaka napsal(a):
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:

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

Again, using "gem foo" is not best practice IMO.

I have to cite from above links:

The system I use to manage my $LOAD_PATH is not your library / app / tests concern. Whether rubygems is used or not is an environment issue.

Rubygems should be opportunity not must. It is like forcing people to using Vim why they like Emacs (substitute with your favorite editor). Its all about options you have.

1b) Every gem added to Ruby slows down ruby require performance.
Although it looks to be negligible penalty, it is unnecessary penalty at
I don't think this is not the supporting reason for your way of
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).

You can limit the impact, you can improve the algorithm, but you cannot remove it.

Also note that if something is packaged as gem, it doesn't mean automatically that it is using rubygems. I can download the code, unpack it and successfully use it without rubygems. May be it needs more effort, but it doesn't matter.

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

We are not that far yet and I hope we will never be.

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.

Sinatra application and Rails application are applications. Even Merb application is application. These applications are typical that they depends on rubygem(sinatra), rubygem(rails) or something, while they do not provide anything.

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

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.

I did not went through R1.9 packages yes, but it is in my plan. And I am fan of such move, although I am not sure that RubyGems and gem authors always follow the best practices.

With still using ruby 1.8.x, I see no need for changing current directory structure

Neither do I. I am speaking about one concrete Sinatra application (which is by coincidence packaged as a gem).

- By the way I think we should try to import ruby 1.9 on Fedora 16.

Yes, that is good idea and it is on my personal TODO list.

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.

Aha, I was not aware of this option. So it should be mentioned in guidelines and gem2rpm updated accordingly (I will do the modification in my fork).

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.

I know. However, gem command on Fedora has some drawbacks:
1) You can't see what really is gem and what actually is rpm packaged gem.
2) Uninstalling gem using gem command when this gem is managed by rpm is not wise.
3) The same apply for example for "gem pristine" command (btw installing gem in cache folder is redundant IMO).

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

I am not against gems. I am not against current packaging based on gems. I just believe that for some applications, it is suboptimal and does not provide any benefits, just confusion. And since I am not aware about any other similar application in Fedora, I am afraid that creating this first package wrong will introduce dangerous precedent. I would like to avoid it. You see my desire to do this package the right way, not necessarily the easiest way.

ruby-sig mailing list