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
Hey to start off, anyone that missed it on Fedora Planet should read
Pavol Rusnak's excellent blog post
(http://stick.gk2.sk/blog/2010/01/gemcutter-opensuse-build-service-cooperati…)
about the state of rubygems, specifically with gemcutter becomming the
official rubygems source
(http://update.gemcutter.org/2009/10/26/transition.html) and the
introduction of the new gemcutter webhook API to register callbacks to
be invoked upon gem updates
(http://gemcutter.org/pages/api_docs#webhook). Also discussed is
gem2rpm, which automatically converts a gem to a rpm specfile / srpm,
and the need of a tool to bind those two components together.
Introducing Polisher which does just that, a rails based webapp that
allows a user to add any number of gem sources, customize the packages
they want to track, and register handlers to be invoked on certain gem
events. Currently I have handlers to simply send an email, and/or
generate a rpm artifact from the gem, and the interface is extensible
enough so that anyone can add any event handler easily. I am currently
working on a module that will automatically submit a bugzilla request
for the gem/rpm. This will entail a feature akin to the 'dirty bit'
discussed in Pavol's blogpost, for packages that need extra maintenance
before submission, but polisher will still assist in the process in any
case (and its possible we can develop a maintenance automation system
which runs a maintainer's scripts to make changes to the package before
bugzilla submission).
It is still early in development, the current state is the result of
only a few days of coding, but I think it's already useful for the Ruby
-> Fedora process. Lots of things still need to be added, there is
no-multiuser support currently for example, but I'm already able to
register callbacks for gemcutter gems, which upon being updated, get
invoked.
Polisher is a webapp since the gemcutter webhook API takes a http url
which to invoke w/ POST params upon a gem update. Whoever will want to
run this will need a public-facing domain to do so. I put a copy up on
my personal domain, feel free to give it a try, just please don't try to
stress test it ;-) (and forgive the simplistic interface, was going for
functional/quick).
http://projects.morsi.org/polisher/demo
At some point, if this takes off, it would be awesome to get some
hosting space for the Fedora community, and to setup an automated
Ruby->Fedora workflow engine, w/ maintainer intervention at the
appropriate points. Also what are everyone's thoughts on a dedicated
rubygem yum repository for Fedora, something that could be optionally
added by any user independently of the core Fedora repos and have all
the greatest / latest versions of all the rubygems. Just a random idea
that I had, not sure about the feasibility / everything that would be
entailed.
The polisher source is licensed under the gpl and can be downloaded from
github:
http://github.com/movitto/polisher
I also pushed the polisher gem to the gemcutter repo and you can install
it w/
gem install polisher
provided you have a recent enough version of rubygems (w/ gemcutter
officially part of the repo list).
Feel free to send any thoughts or questions to me on/off list.
-Mo
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
