Ruby 1.9.3 testing repository

Vít Ondruch vondruch at
Mon Dec 19 12:43:53 UTC 2011

Dne 17.12.2011 19:26, TASAKA Mamoru napsal(a):
> Hello,
> Vít Ondruch wrote, at 12/14/2011 10:33 PM +9:00:
>> Hi,
>> I have uploaded updated version of Ruby 1.9.3 packages into my 
>> testing repository.
>> They are probably very close to the shape of Ruby I'd like to see in 
>> future Fedoras.
> First of all, I appreciate your work on ruby 193 packaging. Then I 
> leave some quick
> comments now.

Thank you for your great feedback!

>> The main changes are:
>> - Install RubyGems library outside of Ruby directory structure into 
>> /usr/share/rubygems folder.
>>   This should allows us to share RubyGems among different Ruby 
>> implementations.
>> - Installed gems are now divided into different directories. Gems 
>> installed by regular user goes into his/her home directory,
>>   gems installed by root goes to /usr/local/ directory, while the 
>> gems installed by RPM will go into /usr directory.
> I don't this behavior is right. If gems installed by regular users 
> goes into under their home
> directory, so should be on root because root is one of the users and 
> we should prevent root's
> installing gems under root's home directory.

root user is exceptional anyway. Even his home directory is not in the 
same location as other users have. So I believe that this behavior is 
justifiable, although not everyone will necessarily agree. Preferred way 
of installing gem is using RPM anyway. Moreover, if you really like to 
install gems into root's home directory, you have still plenty of 
options such as GEM_HOME or --install-dir.

>> - "gem install" now installs gems into share/gems directory while 
>> their binary extensions goes into lib{64}/gems
>>   directory. This (in theory) allows to install binary gems side by 
>> side without conflicts.
>> - RubyGems has now its own -devel subpackage, which will be need in 
>> the future for build of RPM packages.
>> - Enhanced macros.ruby and macros.rubygems.
>> - All tests are green now (credits goes to bkabrda).
>> The detailed changelog you can find at GitHub repo [1].
> Some packaging issue.
> - Please check directory ownership issue.
>   - For example, the directory %{ruby_libarchdir}/digest/ or so are 
> not owned by
>     any packages.
>   - The directory %_libdir/pkgconfig should not be owned by ruby-devel.
> - The dependency of -tcltk subpackage on -libs package should be %_isa 
> specific.

These are all valid points. I'll fix them.

> - Maybe ri directory should be moved to %_libdir/ri for now?

Are you referring to my TODO [2]? Since this is really tricky. I agree 
that, if I claim that the RI documentation is platform specific, it 
should go into the %{_libdir}, on the other side this is bug IMO and I 
believe that it was also agreed by upstrem.

> - It seems that %{ruby_libdir}/rbconfig should belong to rubygems, not 
> ruby-libs.

If you check RubyGems upstream [3], you'll see that it contains only the 
"datadir.rb" file, therefore it means the "obsolete.rb" is own by Ruby 
ant herefore the rbconfig dir has to be owned by Ruby, not RubyGems. 
Also, RbConfig is clearly feature or Ruby. However, according to what I 
mentioned above, I have to exclude "datadir.rb" from Ruby and include in 
RubyGems package.

> - build.log just shows:
> --------------------------------------------------
> compiling main.c
> compiling dmydln.c
> compiling dmyencoding.c
> compiling version.c
> --------------------------------------------------
>   or so, It is hard to check from this log if Fedora specific 
> compilation flags are
>   passed correctly or not. Please make build.log more verbose so that 
> we can
>   see what commands are actually executed during build.

You are right that build of 1.8.7 was more verbose. However I can't see 
any difference in configuration or make flags. I'll try to take a look 
into it but I can't promise.

> - Isn't COPY="cp -p" needed also on %install? Also
>   "cp %{SOURCE1} %{buildroot}%{rubygems_dir}/rubygems/defaults"
>   in %spec file should be replaced by "cp -p".

Is it required at all? It is not used even in %install of 1.8.7, but 
there might be different reason. However there is guideline [5], so it 
is probably good idea.

> - Consider to move mkmf.rb to ruby-devel:
> --------------------------------------------------
> <mock-chroot>[root at localhost /]# rpm -q ruby
> ruby-
> <mock-chroot>[root at localhost /]# rpm -q ruby-devel
> package ruby-devel is not installed
> <mock-chroot>[root at localhost /]# ruby -e "require 'mkmf'"
> mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
> --------------------------------------------------

Actually this is interesting idea. Never thought about it.

> - rubygems rpm contains "bigdecimal-1.1.0.gemspec  io-console-0.3.gemspec
>   json-1.5.4.gemspec minitest-2.5.1.gemspec"??
>   - At least these components should have its own subpackage rpms.
>   - Also, for example the latest minitest is 2.9.1. rubygems (or 
> rubygem-minitest
>     built from ruby.... too complicated) should use latest minitest
>   (and also please re-check components bundled in ruby - I hope
>    ruby upstream will again unbundle these components ... this is
>    again too complicated ..)

Yes, it is on my TODO list, however not a big priority. I believe that 
we can work on it later and can't see any immediate problem with that.

> - include/ruby/ contains origuruma.h, however origuruma is separately
>   packaged on Fedora.
>   Can ruby use system-widely provided origuruma?
>   If not, what prevents it?

This is though. I remember this lengthy discussion [4] about (not only) 
oniguruma and from that, I had the feeling that the upstream version is 
not compatible with Ruby. Moreover, I checked the latest sources from 
Fedora and from Ruby and they differs. I cannot imagine to patch Ruby to 
support the upstream library, although we can try to open request 
upstream? What do you think?

> If you have previously installed Ruby
>> 1.9.3 from my testing repository, you should be able to simply do:
>> # yum update ruby
>> However, please note that due to directory structure changes, you 
>> might need reinstall all your gems.
>> And as always, any feedback is appreciated.
>> Vit
>> [1]
> Regards,
> Mamoru
> _______________________________________________
> ruby-sig mailing list
> ruby-sig at


More information about the ruby-sig mailing list