Ruby 1.9.3 testing repository

[Bohuslav Kabrda]

----- Original Message -----
> From: "TASAKA Mamoru" <mtasaka at fedoraproject.org>
> To: "Ruby SIG mailing list" <ruby-sig at 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 at localhost /]# rpm -q ruby
> ruby-1.9.3.0-2.fc17.i686
> <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
> --------------------------------------------------
> - 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/ruby-sig