Hello:

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: https://bugzilla.redhat.com/show_bug.cgi?id=513048#c9
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: 
https://bugs.ruby-lang.org/projects/ruby/wiki/StdlibGem
- 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).

Regards,
Mamoru


_______________________________________________
ruby-sig mailing list
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig

Reply via email to