Feature #5617: Allow install RubyGems into dediceted directory

• Status: Assigned
• Assignee: hsbt (Hiroshi SHIBATA)
• Target version: -

[vo.x (Vit Ondruch)]

Hello,

I would like to propose my patch, which allows to optionally install RubyGems library into dedicated directory, out of the default Ruby directory structure. This should enable to easily share one RubyGems library by more Ruby implementations and avoids code duplication. I did this patch since Fedora prohibits duplication of system libraries [1], which would be the case if MRI and JRuby are installed in parallel.

Thank you for considering this patch.

Vit

[1] https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries

[vo.x (Vit Ondruch)]

• File 0002-Avoid-duplication-of-datadir.rb-which-belongs-to-Rub.patch 0002-Avoid-duplication-of-datadir.rb-which-belongs-to-Rub.patch added

Remove duplicated datadir.rb

[kosaki (Motohiro KOSAKI)]

• Status changed from Open to Rejected

% autoconf
/usr/bin/gm4:configure.in:2826: Warning: too few arguments to builtin `patsubst'
autom4te: /usr/bin/gm4 failed with exit status: 1

You have to run your patch BEFORE upload it. :-/

[vo.x (Vit Ondruch)]

Actually I ran the patch. The updated version is available here: https://github.com/voxik/ruby.spec/blob/master/ruby-1.9.3-custom-rubygems-location.patch

[vo.x (Vit Ondruch)]

To be precise, the github patch is fixed version of 0001-Allow-to-install-RubyGems-into-custom-location-outsi.patch. The 0002-Avoid-duplication-of-datadir.rb-which-belongs-to-Rub.patch still needs to be applied. I'll upload correct version of the 0001 tomorrow, since I'm working on different computer now.

Please reopen the issue.

[Eregon (Benoit Daloze)]

Hello,

I would be very interested to have a way to tell RubyGems to install at a particular shared path by default (to avoid unnecessary duplication), but only for the gems which are not implementation-dependents (e.g.: C extension should be installed in an unshared path of course).

I think this should be done in RubyGems's code, instead of an option in the configuration process (it would also avoid to do the work for each implementation).

What do you think?

P.S.: The duplication is especially bad since it means I must install all my (n) dependencies on every implementation/version when I want to test on them, which means m*n gem install (or fetching the repository) which could just be n if the gems contain only implementation-independent code.

[vo.x (Vit Ondruch)]

Benoit Daloze wrote:

Hello,

I would be very interested to have a way to tell RubyGems to install at a particular shared path by default (to avoid unnecessary duplication), but only for the gems which are not implementation-dependents (e.g.: C extension should be installed in an unshared path of course).

I think this should be done in RubyGems's code, instead of an option in the configuration process (it would also avoid to do the work for each implementation).

What do you think?

Actually this two patches are just subset of patches I'd like to introduce into Fedora. You can find all the patches in my repository [1]. Some of them, like this one, are more Ruby specific, others are RubyGems specific [2].

If you go through this patch, you'll see that this patch is definitely Ruby specific. It allows to install RubyGems into dedicated directory (specifiable by configuration parameter) and extends Ruby's search path to include this path.

There might be also required patch to RubyGems's setup.rb to allow to install updated RubyGems into this location, but first, I'd like to see this feature accepted.

Please note that this feature is just optional and it keeps the current Ruby+RubyGems behavior intact unless requested.

[1] https://github.com/voxik/ruby.spec/
[2] https://github.com/rubygems/rubygems/issues/210

[kosaki (Motohiro KOSAKI)]

I think this should be done in RubyGems's code, instead of an option in the configuration process (it would also avoid to do the work for each implementation).

What do you think?

Actually this two patches are just subset of patches I'd like to introduce into Fedora. You can find all the patches in my repository [1]. Some of them, like this one, are more Ruby specific, others are RubyGems specific [2].

If you go through this patch, you'll see that this patch is definitely Ruby specific. It allows to install RubyGems into dedicated directory (specifiable by configuration parameter) and extends Ruby's search path to include this path.

There might be also required patch to RubyGems's setup.rb to allow to install updated RubyGems into this location, but first, I'd like to see this feature accepted.

Please note that this feature is just optional and it keeps the current Ruby+RubyGems behavior intact unless requested.

What's happen if a user install non-rpm gems? If it's installed into
fedora's "dedicated directory", some ruby interpreter may access it
and makes SEGV.

[vo.x (Vit Ondruch)]

Motohiro KOSAKI wrote:

What's happen if a user install non-rpm gems? If it's installed into
fedora's "dedicated directory", some ruby interpreter may access it
and makes SEGV.

I am not sure I understand your point, but I'll try to elaborate a bit. With this patch there are two scenarios:

1. The default is that everything works as it worked now. I.e. you download the Ruby tarball, you don't care about any configuration options, everything is installed in default including RubyGems under Ruby directory.

2. You are user who cares about duplication of system libraries or you may be like to share gems between two interpreters (with all the consequences), therefore there is this configuration option "--with-rubygemsdir" if user likes.

I see no chances that "random ruby interpreter may access some inappropriate gem and SEGV" unless the user explicitly wants.

If you are using RPM managed gems (but also other software), it gets installed into /usr. If you like to install your own software from tarball, it should go into /usr/local. Again, I see no chance to collide unless you explicitly want.

The main reason for Fedora for this switch is to avoid duplication of system libraries, e.g. to allow MRI and JRuby to share the RubyGems library itself. This switch is one step forward to achieve this goal.

[kosaki (Motohiro KOSAKI)]

I meant,

• the user use "--with-rubygemsdir" ruby binaries, and
• use unpatch gems

Why the gems should go into /usr/local? Who care?

[vo.x (Vit Ondruch)]

• File 0003-Removed-superfluous-bracket.patch 0003-Removed-superfluous-bracket.patch added

Motohiro KOSAKI wrote:

% autoconf
/usr/bin/gm4:configure.in:2826: Warning: too few arguments to builtin `patsubst'
autom4te: /usr/bin/gm4 failed with exit status: 1

You have to run your patch BEFORE upload it. :-/

0003-Removed-superfluous-bracket.patch fixes the issue.

[vo.x (Vit Ondruch)]

Motohiro KOSAKI wrote:

I meant,

• the user use "--with-rubygemsdir" ruby binaries, and
• use unpatch gems

RubyGems library is in charge where to install your gems. Here [1] is the logic and I am not touching it in this patch. That means only RubyGems library is installed into the custom location while the gems are installed into location specified by RubyGems.

Why the gems should go into /usr/local? Who care?

It is good habit to place right content into right folders. You probably don't save your documents into /etc or /tmp just because you can. There are standards [2] which describes what should be placed where. It is definitely good idea to not intermix software installed by RPM and by you manually. Therefore there are different locations for that purposes.

Speaking as a Ruby maintainer of Fedora, it is definitely my responsibility to cultivate good habits and place software where it belongs. I understand that Ruby supports more OSes with different needs and different standards, therefore my patch does not change any defaults, but allow to support needs of my platform. Btw I am using Ruby also on Windows and there is definitely no need for such configuration option, but it definitely does not harm anybody.

[1] https://github.com/rubygems/rubygems/blob/master/lib/rubygems/defaults.rb#L21-44
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html

[naruse (Yui NARUSE)]

• Status changed from Rejected to Assigned
• Assignee set to drbrain (Eric Hodel)

• Show standalone patch; a patch to previous patch is difficult to inspect
• How will users use gems with this patched ruby?

[vo.x (Vit Ondruch)]

• File Allow-to-install-RubyGems-into-custom-location-outsi.patch Allow-to-install-RubyGems-into-custom-location-outsi.patch added

Yui NARUSE wrote:

• Show standalone patch; a patch to previous patch is difficult to inspect

Here is the squashed version.

• How will users use gems with this patched ruby?

There is no difference at all IMO.

[drbrain (Eric Hodel)]

• File custom_rubygems_location.patch custom_rubygems_location.patch added
• Category set to build
• Assignee changed from drbrain (Eric Hodel) to matz (Yukihiro Matsumoto)

This functionality is fine with me, but since it applies to the build system and not RubyGems I think matz or someone else should decide if it should be applied.

I had to manually apply one chunk of this patch, so I attached an updated version.

[nobu (Nobuyoshi Nakada)]

• AC_DEFINE_UNQUOTED(RUBYGEMS_DIR,"$rubygemsdir")

[nobu (Nobuyoshi Nakada)]

=begin
Add !! mark

• AC_DEFINE_UNQUOTED(RUBYGEMS_DIR,"$rubygemsdir")
  =end

[vo.x (Vit Ondruch)]

• File 20120606-Allow-to-install-RubyGems-into-custom-location-outsi.patch 20120606-Allow-to-install-RubyGems-into-custom-location-outsi.patch added

I am attaching updated patch with added !!

[vo.x (Vit Ondruch)]

Ping. Any possibility to accept this patch please?

[mame (Yusuke Endoh)]

• Target version set to 2.6

[vo.x (Vit Ondruch)]

Here is recent version of the patch against ruby 2.1.0 preview1

http://pkgs.fedoraproject.org/cgit/ruby.git/tree/ruby-2.1.0-custom-rubygems-location.patch?h=private-ruby-2.1

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[mame (Yusuke Endoh)]

• Assignee changed from matz (Yukihiro Matsumoto) to hsbt (Hiroshi SHIBATA)

[hsbt (Hiroshi SHIBATA)]

• Related to Feature #19972: Install default/bundled gems into dedicated directories added