RubyGems packaging with Ruby 2.1.0

[Vít Ondruch]

Hi rubyists,

Working toward Ruby 2.1.0 in Fedora, there are going to be necessary 
some changes to gems with binary extensions. In short, the extensions 
are not installed into %{buildroot}%{gem_extdir_mri}/REQUIRE_PATHS/ 
anymore, but %{buildroot}%{gem_extdir_mri}/ will be used for the future. 
This is improvement and this change is coming from RubyGems upstream. It 
should also simplify the guidelines a bit [1] (on the first look).

Unfortunately, although the resulting rubygem- packages are much nicer 
and closer to upstream then they used to be, the way how to create them 
got uglier :/ You can see changes needed to make rubygem-bcrypt-ruby 
compatible with new RubyGems in attached diff.

Since I am not happy about the situation, I'd like to ask you for your 
feedback, how would you envision to simplify this process.

I am thinking about several possibilities:

1) Modify our operating_system.rb and let it treat gem installation into 
%{buildroot} specially
2) Use some environment variable, to let RubyGems know, that we need to 
treat %{buildroot} similarly to system directories
3) Introduce some additional parameter to gem install command, which 
will modify the --install-dir option to install extensions properly
4) Introduce some RPM macros which will handle all this stuff for us.

Please let me know if you have another bright idea :)


Thanks



Vít


[1] https://fedoraproject.org/wiki/Packaging:Ruby#Building_gems

[Vít Ondruch]

Dne 23.12.2013 18:24, Vít Ondruch napsal(a):
>  1) Modify our operating_system.rb and let it treat gem installation
>  into %{buildroot} specially 
I went ahead with this option and this [1] is the implementation. In
attachment, you can see the changes needed to rubygem-bcrypt-ruby.spec.
Few comments:

* I am going to backport patches to remove the "rm -rf
%{buildroot}%{gem_dir}/doc/extensions" need.

* Not sure if there is some neat way how to get rid of the
"-I%{buildroot}%{gem_extdir_mri}" from the %check section though :/ May
be "-I$(dirs +1)%{gem_extdir_mri}" could be better pattern, since it
points into ${_builddir}, i.e. into the directory where the test suite
is executed. Any thoughts on this topic?


Vít





[1]
http://pkgs.fedoraproject.org/cgit/ruby.git/commit/?h=private-ruby-2.1&am...

[Mo Morsi]

On 01/10/2014 09:11 AM, Vít Ondruch wrote:


>  * Not sure if there is some neat way how to get rid of the
>  "-I%{buildroot}%{gem_extdir_mri}" from the %check section though :/ May
>  be "-I$(dirs +1)%{gem_extdir_mri}" could be better pattern, since it
>  points into ${_builddir}, i.e. into the directory where the test suite
>  is executed. Any thoughts on this topic?
>
>  
Could the buildroot correspondences of the standard ruby load
directories be automatically pushed onto the LOAD_PATH in the %check
section? Then the buildroot would just be seen as another standard
location to all the ruby based tools. Or perhaps some more macro's could
be used to hide some of these long bits.

Just my 2cents,
  -Mo

[Vít Ondruch]

Dne 21.1.2014 01:54, Mo Morsi napsal(a):
>  On 01/10/2014 09:11 AM, Vít Ondruch wrote:
>
>
> > * Not sure if there is some neat way how to get rid of the
> > "-I%{buildroot}%{gem_extdir_mri}" from the %check section though :/ May
> > be "-I$(dirs +1)%{gem_extdir_mri}" could be better pattern, since it
> > points into ${_builddir}, i.e. into the directory where the test suite
> > is executed. Any thoughts on this topic?
> >
> >
>  Could the buildroot correspondences of the standard ruby load
>  directories be automatically pushed onto the LOAD_PATH in the %check
>  section? Then the buildroot would just be seen as another standard
>  location to all the ruby based tools. Or perhaps some more macro's could
>  be used to hide some of these long bits. 
Pushing buildroot on LOAD_PATH is not enough. More likely, you have
something like GEM_PATH=%{buildroot}%{gem_dir} on your mind.
Unfortunately that will not work as well, since it is not standard
system path, so there is not expected that extensions are placed into
%{gem_extdir_mri}.


Vít