----- Original Message -----
From: "TASAKA Mamoru" <mtasaka(a)fedoraproject.org>
To: "Ruby SIG mailing list" <ruby-sig(a)lists.fedoraproject.org>
Sent: Saturday, December 17, 2011 7:26:20 PM
Subject: Re: Ruby 1.9.3 testing repository
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.
> 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.
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.
> - "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.
- Maybe ri directory should be moved to %_libdir/ri for now?
- It seems that %{ruby_libdir}/rbconfig should belong to rubygems,
not ruby-libs.
Why? It contains information about ruby, not about rubygems.
- 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.
- 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".
- Consider to move mkmf.rb to ruby-devel:
--------------------------------------------------
<mock-chroot>[root@localhost /]# rpm -q ruby
ruby-1.9.3.0-2.fc17.i686
<mock-chroot>[root@localhost /]# rpm -q ruby-devel
package ruby-devel is not installed
<mock-chroot>[root@localhost /]# ruby -e "require 'mkmf'"
mkmf.rb can't find header files for ruby at /usr/share/include/ruby.h
--------------------------------------------------
- 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.
- include/ruby/ contains origuruma.h, however origuruma is
separately
packaged on Fedora.
http://koji.fedoraproject.org/koji/packageinfo?packageID=5432
Can ruby use system-widely provided origuruma?
If not, what prevents it?
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]
https://github.com/voxik/ruby.spec
Regards,
Mamoru
Regards,
Bohuslav.
_______________________________________________
ruby-sig mailing list
ruby-sig(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/ruby-sig