[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#27438] [PATCH] Specify native search path for all ruby packages

From: Christopher Baines
Subject: [bug#27438] [PATCH] Specify native search path for all ruby packages
Date: Thu, 22 Jun 2017 06:40:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0

On 22/06/17 06:27, Ben Woodcroft wrote:
> On 21/06/17 23:12, Ludovic Courtès wrote:
>> Ben Woodcroft <address@hidden> skribis:
>>> On 21/06/17 16:36, Christopher Baines wrote:
>>>> Without specifying this explicitly in each definition, the GEM_PATH is
>>>> inherited and the version is that of the inherited package.
>>> I'm not sure if this is by design, but the version of the gems folder
>>> is embedded in the build of each rubygem e.g. 'ruby-hoe' includes
>>> /gnu/store/d867l5i2dqd5qnq4qlsrcwwb0x3443fl-ruby-hoe-3.16.0/lib/ruby/gems/2.4.0
>> Or should the search path spec include both lib/ruby/gems/2.2.0 and
>> lib/ruby/gems/2.4.0, in this order?
> Exactly.
> Chris, what is your experience? Did you propose the patch because you
> ran into a particular issue?

Yep, I ran in to problems trying to use the guix ruby-2.3 package with
the guix bundler package, when I build bundler with ruby-2.3.

Ben's email got me thinking about how this works in Debian, and it looks
like Debian uses a different location /usr/lib/ruby/vendor_ruby/ .

I think there might be benefits from doing similarly, but this needs a
bit of thought and testing, as I'm unsure how this might work,
especially in cases where libraries include native code that links
against ruby.

I've got a patch for the ruby-build-system to make a change roughly like
this, and I'll send that up soon. Relating this back to the issue at
hand, moving to a version independent directory would mean that the
GEM_PATH wouldn't be version specific.



Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]