ruby-sig December 2009

ruby-sig@lists.fedoraproject.org

8 participants
6 discussions

The Ruby World Domination Plan
by Jeroen van Meeuwen 10 Feb '10

10 Feb '10

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

5 8

ruby versions api compatability
by Mo Morsi 06 Jan '10

06 Jan '10

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-us…). 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

4 5

self intro & mxmas
by "Guillermo Gómez S." 24 Dec '09

24 Dec '09

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

2 1

Re: The Ruby World Domination Plan
by Ben Shakal 24 Dec '09

24 Dec '09

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

1 0

rubygem based rawhide packages stats on 2009-12-21
by Mamoru Tasaka 22 Dec '09

22 Dec '09

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

3 6

rubygem-haml
by Michal Babej 02 Dec '09

02 Dec '09

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

3 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

ruby-sig December 2009