Apologies in advance for the long email.
Currently, OpenBSD supports four ruby interpreters (ruby 1.8,
ruby 1.9, jruby, and rubinius). Most ruby libraries in the ports
tree can be built for multiple interpreters (using ruby19, jruby,
and rbx FLAVORs). Most ports in the tree are only built for
ruby 1.8 by default, though most ports that include C extensions
are built for both ruby 1.8 and ruby 1.9.
ruby 1.8 is no longer maintained upstream other than for security
fixes, and starting in June 2013, it will be completely unmaintained
upstream.
By the time 5.3 is relased in May 2013, it is likely that support
for ruby 1.8 will start being dropped in the major ruby libraries.
Rails 4 is dropping support for ruby 1.8, and I expect many ruby
libraries will follow suit. I don't think it makes sense
to be shipping mostly ruby 1.8 packages in 5.3, so my major pre-5.3
goal is switching the ports tree so that most ports use ruby 1.9 by
default. Any ports that are currently built for both ruby 1.8 and
ruby 1.9 will continue to be built for both.
There are two main ways I can think to accomplish that. The first
is to just change the category Makefiles to add the ruby19 flavor
to the ruby ports that are currently unflavored.
Another possible way to handle this would be to keep ruby 1.9 ports
using the ruby19 FLAVOR, but switch ruby 1.8 ports to use a ruby18
FLAVOR, and have unFLAVORed builds just default to the ruby19
FLAVOR. I'll consider that approach if the @conflict markers can be
added to the PLIST automatically by ruby.port.mk for ruby18 ports.
Advantages of just adding ruby19 FLAVOR to category Makefiles:
* ruby.port.mk already has a lot of magic (maybe too much magic),
and this won't add additional magic.
* This can be done a port at a time, instead of all at once.
* Doesn't require REVISION bumping all ruby ports.
Advantages of making ruby19 the default FLAVOR, with a new
ruby18 FLAVOR for ruby 1.8 packages:
* Running "make package" in a ruby port will built the ruby 1.9
package instead of the ruby 1.8 package.
* Should we need to change the default in the future (2.x->3.0),
it's as simple as changing the default FLAVOR used.
* Doesn't require as many changes to category Makefiles.
I'm leaning toward making the ruby19 FLAVOR the default, assuming
I can get that to work.
I foresee a few issues with this change. First, many ruby ports in
the tree are badly out of date, and probably can't just move to
1.9 by default. I'd like to either bring these ports up to date and
move them to ruby 1.9 mode, or delete them from the tree.
For people that already have ruby 1.8 packages installed, switching
the ports system to build ruby 1.9 packages by default should not
cause problems. It will just mean that when they run pkg_add -ui,
it won't find updates for those ruby 1.8 packages.
Personally, I don't see a need for providing ports/packages for most
ruby libraries, except in the following cases:
1) The library contains a C extension. I'm in favor of providing
ports/packages for ruby libraries with C extensions, since whenever
you update your system to a new snapshot/release, you are generally
going to need to recompile the C extension, and pkg_add -ui will
handle that update for you. Example: www/ruby-unicorn.
2) The library requires patching to work on OpenBSD. There are only
a few cases of ruby libraries that actually need to get patched to
work on OpenBSD. Most of the in-tree patches in ruby ports are to
get the regression tests working, not the library itself. Example:
devel/ruby-rake-compiler.
3) The library is a dependency for something else in tree, in which
case it has to be packaged. Example: www/ruby-rack (dependency of
www/ruby-unicorn).
For a pure ruby library that doesn't require patching to work and
doesn't have any in-tree dependencies (referred to below as
"needless ports"), I don't think it makes sense to maintain a port
for it. The results of installing the package are pretty much the
same as using "gem install" to install the library.
My plan of action:
1) Review the existing ruby ports in the tree, see what builds with
ruby 1.9 and what doesn't.
2) If it doesn't build on ruby 1.9 and is a needless port, email
the maintainer, seeing if they are still interested in maintaining
it, and if they are, to update it so that it works on ruby 1.9 (or
give a reason why we should keep it as a 1.8 port). If there is no
maintainer or the maintainer is no longer interested, ask on
ports@ if anyone wants to maintain the port, and if nobody steps
up, remove the port from the tree.
3) Make the switch to build most ruby ports in 1.9 mode by default.
I'd appreciate any thoughts/objections/recommendations related to
this.
Thanks,
Jeremy
