Ruby 1.9.3 testing repository

TASAKA Mamoru mtasaka at
Mon Dec 19 14:48:29 UTC 2011


Bohuslav Kabrda wrote, at 12/19/2011 06:06 PM +9:00:
>>> - 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.
> I don't quite understand what you are saying - in one sentence you say that
>we should install gems in root home because root is just another user and
> then you say that we should prevent it. Personally, I think the Vit's proposed
> behaviour is right, as root is not (should not) be used for development/running
> applications and therefore there is no need for gem directory in his home.
> At the same time, root should be able to install non-rpm gems if he wants to
>make their new/unpackaged versions available system-wide.

Note this:
CVE-2007-0469, still open)

(Although I left some comment that I don't agree on that bug) security responsible
team complains about _default_ behavior of installing system-wide even with root.
(Again although I left some comments that I don't agree with this) I think
changing _default_ behavior between root and normal users just introduces
unneeded confusion.

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

It seems that I got confused between /usr/share/ruby/rbconfig and
/usr/share/rubygems/rbconfig ... however now why they both exist?
(ruby-18 does not have /usr/share/ruby/rbconfig and rubygems 1.8.11
with ruby-18 contains /usr/lib/ruby/site_ruby/1.8/rbconfig)

Note that /usr/lib/ruby/rbconfig.rb is there and "RbConfig" means
this > Vit

>> - 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 ..)
> There has already been a proposal to gemify standard library:
> - the question is, when it will really happen. For now, I agree we should look into moving these gems into subpackages
> (Is it even possible/feasible? Will everything work if we update them to newer versions?) and _consider_ it.

If newer versions don't work, then it is a bug on such submodule, as people is
always able to upgrade individual submodule by themselves.
(Well, perl approach may be applicable).


More information about the ruby-sig mailing list