The Ruby World Domination Plan
by Jeroen van Meeuwen
Hi guys,
after FUDCon, and then some more thoughts in private email and between
my ears, I think I might have the bare bones for a plan to attack the
Ruby challenge;
First of all, let me emphasize that the complete plan is based on the
fact we want different Ruby stacks to be available, namely those Ruby
stacks that someone might target (in development). That said, I think
the list of Ruby stacks one can target right now are:
- ruby-1.8.5 as shipped in EL-5
- ruby-1.8.6 as shipped in Fedora currently, and most likely also EL-6
- ruby-1.9.1 as targeted for Fedora 13
The goal of this thread is to figure out what we should do in terms of
packaging, but having given it a little thought here's how I think I
would prefer to attack the problem. Please bear with me when I start of
rambling 'cause I don't know how to put this in an overview that
everyone understands (but we'll get there);
- Ruby packages themselves are to be named ruby-<major>.<minor>.<teeny>,
as to not have to rename packages to compat-ruby every time a newer
M.M.T is released.
- A base 'ruby' (e.g., the package's %{name} == "ruby") package will
pull in the default stack (targeted to be ruby-1.9.1 in Fedora 13).
- The ruby-<m>.<m>.<t> packages are going to provide:
1) ruby(ABI) = <major>.<minor>
2) ruby(ABI) = <major>.<minor>.<teeny>
3) ruby(API) = <major>.<minor>
4) ruby(API) = <major>.<minor>.<teeny>
The Ruby ABI is pretty stable in between teeny versions, but much less
so for the Ruby API.
- The base directory for Ruby modules is going to be %{ruby_vendorlib}
and %{ruby_vendorarch}, provided through /etc/rpm/macros.ruby, resulting
in /usr/share/ruby/ and %{_libdir}/ruby/.
This is where packaged gems and library extensions to Ruby should end up
initially. If gems turn out to be compatible with one specific Ruby
version only, one can use %{ruby_vendorlib_186} (again provided through
/etc/rpm/macros.ruby), or if a gem is compatible with 1.8.x,
%{ruby_vendorlib_18} should be used.
gems and library extensions installed manually should end up in the
appropriate /usr/local/ directories, which will also appear first in
each of ruby's search paths.
- Search paths are going to look similar to:
/usr/local/lib{,64}/ruby/<major>.<minor>.<teeny>/
/usr/local/lib{,64}/ruby/<major>.<minor>/
/usr/local/lib{,64}/ruby/
/usr/local/share/ruby/<major>.<minor>.<teeny>/
/usr/local/share/ruby/<major>.<minor>/
/usr/local/share/ruby/
/usr/lib{,64}/ruby/<major>.<minor>.<teeny>/
/usr/lib{,64}/ruby/<major>.<minor>/
/usr/lib{,64}/ruby/
/usr/share/ruby/<major>.<minor>.<teeny>/
/usr/share/ruby/<major>.<minor>/
/usr/share/ruby/
as to make sure that rubygem-foo can be packaged for all ruby versions
easily, while making the exception (ruby version specific patch?) is
also perfectly feasible (by putting another copy in the more specific
search path).
To illustrate my packaging points, I would appreciate if you look at the
following git repository, where I keep a couple of .spec files as well
as the macros.ruby file I intend to use:
git://fedorapeople.org/home/fedora/kanarip/public_git/ruby-specs.git
Along with that comes a git repository for Ruby itself, to be found at:
git://fedorapeople.org/home/fedora/kanarip/public_git/ruby.git
Preliminary packages can be found on:
For Fedora 12:
- http://www.kanarip.com/custom/f12-ruby/ and
- http://mirror.nl.kanarip.com/custom/f12-ruby/
For Fedora Rawhide:
- http://www.kanarip.com/custom/rawhide-ruby/ and
- http://mirror.nl.kanarip.com/custom/rawhide-ruby/
That said, these packages could ruin your current Ruby stack (different
search paths and all that).
Please be so kind as to test these versions and provide me with the
necessary feedback, so we can move things along.
Thanks in advance,
Kind regards,
Jeroen van Meeuwen
-kanarip
13 years, 10 months
ruby versions api compatability
by Mo Morsi
Hey Jeroen, thanks alot for your Ruby roundtable discussion at FUDCon. I
was looking around for various solutions to the Ruby version
compatibility problem for Fedora/Yum and recalled the 'alternatives'
utility which I believe might help out w/ this problem as well.
It is shipped as part of the 'chkconfig' package so it's pretty standard
on Fedora, and was (according to the manpage) originally written for
this same problem w/ Perl.
http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
I recall using it a while back to install various various of Java side
by side in a single environment (pretty good overview here
http://lanestechblog.blogspot.com/2008/03/using-alternatives-in-linux-to-...).
I could see this being useful if we wanted to support installing many
different versions of the Ruby interpreter or different Ruby
interpreters entirely side by side on a single system.
One thing I'm not currently sure of is how we would handle the different
ruby lib and gem paths depending on which alternative is setup. If we
can swap in the correct lib / gem path depending on which alternative is
selected (systemwide or by the user) we should be good.
Any thoughts on this? It might be a little more complicated than doing
the different vendor/version site dirs alone but might provide a nice
way for multiple version support.
-Mo
13 years, 11 months
self intro & mxmas
by "Guillermo Gómez S."
Hi there, my name is Guillermo Gómez, i just subscribed this list as
quick as i found it, im rubyst and i hope i can help here.
Im also trying to be a pkg-maintainer for Fedora (my first rpm will be
posted some time early 2010).
and btw, mXmas to u and yours :-D
Guillermo Gómez
Old man, learning new tricks, and always trying to help someone else
13 years, 11 months
Re: The Ruby World Domination Plan
by Ben Shakal
On Dec 24, 2009, at 4:02 , Jeroen van Meeuwen wrote:
> # gem install facter
>
> installs facter to /usr/local/share/ruby/gems/facter-<version>, along
> with the facter.gemspec in /usr/local/share/ruby/specifications/ and so
> forth, but facter itself won't work.
I mentioned this in an off-list message to Jeroen (just joined the list now, hello everyone!), but I think the issue comes down to the fact that gem_prelude.rb's implementation of Gem.default_dir doesn't match the implementation in lib/rubygems/defaults.rb. (The latter is the full rubygems 1.3.1 version that ships within ruby 1.9.1.) To me it looks like an upstream bug; I can't imagine why they should be implemented so differently. With default MRI paths, they both return (approximately?) the same results, but with this new structure they don't match. In particular, gem_prelude's version returns a nonsensical path.
You can compare the two versions by simply doing this, in a fresh irb instance:
# the gem_prelude.rb version
>> Gem.default_dir
=> "/usr/lib64/ruby-1.9.1/gems"
# trigger method_missing to swap in the full/real rubygems
>> Gem.asdf
NoMethodError: undefined method `asdf' for Gem:Module
from <internal:gem_prelude>:341:in `method_missing'
from (irb):2
from /usr/bin/irb-1.9.1:12:in `<main>'
# the lib/rubygems/defaults.rb version
>> Gem.default_dir
=> "/usr/local/share/ruby/"
I believe the noisy strace you are seeing is simply ruby's usual Kernel.require process of searching the whole load path. When I modified gem_prelude.rb so that its default_dir agreed with rubygems', suddenly everything else started working too. E.g. "require 'facter'" works for me now, in a fresh irb instance.
I piggybacked my change onto the patch you've already included in your RPM, since you were already tweaking gem_prelude.rb. Patch-to-your-patch attached (same one I emailed directly earlier).
Like I said before though, I think there's an upstream bug here too... why do the default_dir methods work so differently?
-Ben
13 years, 11 months
rubygem based rawhide packages stats on 2009-12-21
by Mamoru Tasaka
Hello, all. This is the first post to this mailing list from me.
Among rubygem related rawhide packages on Fedora, the following
packages are not using the latest gems provided by the upstream.
Please consider to update these.
Note that only rpms based on gems hosted on gems.rubyforge.org
are reported in this mail.
Owner srpm latest Fedora
hpejakle rubygem-coderay 0.8.357 0.8.312-4.fc12
hpejakle rubygem-term-ansicolor 1.0.4 1.0.3-4.fc12
kanarip rubygem-facets 2.8.0 2.5.1-2.fc12
kanarip rubygem-fattr 2.1.0 1.0.3-3.fc12
kanarip rubygem-git 1.2.5 1.2.4-1.fc13
kanarip rubygem-highline 1.5.1 1.5.0-2.fc12
kanarip rubygem-main 4.2.0 4.0.0-1.fc13
kanarip rubygem-mocha 0.9.8 0.9.7-2.fc12
kanarip rubygem-picnic 0.8.1.1 0.8.1-2.fc12
kanarip rubygem-restr 0.5.2 0.5.0-2.fc12
kanarip rubygem-reststop 0.4.1 0.4.0-2.fc12
kanarip rubygem-sqlite3-ruby 1.2.5 1.2.4-5.fc12
laxathom rubygem-json 1.2.0 1.1.9-1.fc13
lkundrak rubygem-configuration 1.1.0 0.0.5-4.fc12
lkundrak rubygem-cucumber 0.5.1 0.4.0-1.fc13
lkundrak rubygem-polyglot 0.2.9 0.2.5-4.fc12
lkundrak rubygem-rack-test 0.5.3 0.4.0-2.fc12
lkundrak rubygem-treetop 1.4.3 1.3.0-1.fc12
lutter rubygem-actionmailer 2.3.5 2.3.4-2.fc13
lutter rubygem-actionpack 2.3.5 2.3.4-2.fc13
lutter rubygem-activerecord 2.3.5 2.3.4-2.fc13
lutter rubygem-activeresource 2.3.5 2.3.4-2.fc13
lutter rubygem-activesupport 2.3.5 2.3.4-2.fc13
lutter rubygem-rails 2.3.5 2.3.4-2.fc13
mcpierce rubygem-RedCloth 4.2.2 4.1.9-7.fc12
mcpierce rubygem-activeldap 1.2.1 1.2.0-4.fc13
mcpierce rubygem-hoe 2.4.0 2.3.3-1.fc12
mcpierce rubygem-rubyforge 2.0.3 1.0.5-1.fc12
mcpierce rubygem-rufus-scheduler 2.0.3 2.0.1-3.fc12
mkent rubygem-RubyInline 3.8.4 3.8.3-4.fc13
mkent rubygem-ZenTest 4.2.1 4.1.4-3.fc13
mkent rubygem-extlib 0.9.14 0.9.13-5.fc13
stahnma rubygem-simple-rss 1.2.2 1.1-6.fc12
wakko666 rubygem-pathname2 1.6.3 1.6.2-6.fc13
This list was automatically generated by
http://mtasaka.fedorapeople.org/scripts/Rubygem-latest-check.sh
Any comments to make this scripts better is appreciated.
Regards,
Mamoru
13 years, 11 months
rubygem-haml
by Michal Babej
Hi,
I'd like to package haml gem. I didn't find any ongoing review so i
assume nobody's working on it; if i'm wrong please let me know.
-- mb
14 years
