The precarious state of jruby in Gentoo

tl;dr jruby in Gentoo will have to go unless we get volunteers to help us with the jruby 1.7 series.

jruby has been available in Gentoo since 2004 and is currently at version 1.6.8. People following jruby will realize that this is a problem: the latest upstream version is 1.7.12 as of this writing. The 1.6 series is also based on ruby 1.8.7 by default. This is a problem since we have removed ruby 1.8 from the tree altogether, and support for it in ruby packages is disappearing fast. jruby 1.6 has a 1.9 mode, but that is based on ruby 1.9.2 where most packages expect at least 1.9.3. We are currently experimenting with defaulting to 1.9.2 mode to extend the 1.6 series. In short, more and more packages that currently have jruby target will loose it on updates since it simply is no longer compatible with jruby 1.7 and in its current state jruby in Gentoo is ready for a slow and agonizing descent. Or we could just be quick about it and mask it soon.

Why not just update to jruby 1.7, you might wonder? We have bug 442230 to track this update, but unfortunately it turns out that it is not easy to add the 1.7 series of jruby to Gentoo. The biggest stumbling block here is that the 1.7 build system is based on Maven. Using Maven is not well supported in Gentoo, mostly because Maven requires the ability to download code during its build phase and does not play very nice with Gentoo's package structure in general. It may be possible to fix this, but that requires good knowledge of Java and Ruby on Gentoo. Currently we don't have any developers capable of both, and passing the code back and forth isn't very practical and proves to go very slow in practice.

So we are looking for a volunteer who wants to pick up this project, and help us bring the jruby 1.7 series to Gentoo. If you see this as a step to become a Gentoo developer than that's great and we can mentor you. If you see this as an interesting one-off project to help out with, that's great too. Once 1.7 is in the tree it should not be a big deal to keep up with new versions. Feel free to drop by in #gentoo-ruby to discuss this with us if you are interested. Our ruby overlay holds the current work-in-progress on jruby 1.7.

If no-one volunteers, unless a magical break-through suddenly appears, we will most likely be forced to mask jruby and remove it from the tree. Help us to not do that!

Published on 23/04/2014 at 17h13 by Hans de Graaff, tags , , , ,

Gentoo Ruby 1.9 and Ruby Enterprise Edition status updates

I've just updated the text on the Gentoo Wiki page on Ruby 1.9 to indicate that we now support eselecting ruby19 as the default ruby interpreter. This has not been tested extensively, so there may still be some problems with it. Please open bugs if you run into problems.

Most packages are now ready for ruby 1.9. If your favorite packages are not ready yet, please file a bug as well. We expect to make ruby 1.9 the default ruby interpreter in a few months time at the most. Your bug reports can help speed that up.

On a related note, we will be masking Ruby Enterprise Edition (ree18) shortly. With Ruby 1.9 now stable and well-supported we no longer see the need to also provide Ruby Enterprise Edition. This is also upstream's advice. On top of this the last few releases of ree18 never worked properly on Gentoo due to threading issues, and these are currenty already hard-masked.

Since we realize people may depend on ree18 and migration to ruby19 may not be straightforward, we intend to move slowly here. Expect a package mask within a month or so, and instead of the customary month we probably won't remove ree18 until after three months or so. That should give everyone plenty of time to migrate.

Published on 26/09/2012 at 19h33 by Hans de Graaff, tags

RUBY_TARGETS default now changed to include both ruby18 and ruby19

Contrary to my earlier post about ruby 1.9 going stable, we've decided to add ruby19 to the default RUBY_TARGETS now, rather than wait a few weeks. The main reason for this is that some packages correctly depend on dev-lang/ruby, and thus pull in ruby 1.9 now that it is stable, but they also pull in supporting packages that need to be installed for ruby 1.9. Without the ruby19 target portage will complain that it lacks the ruby_targets_ruby19 USE flag for these packages and it suggests to add them to package.use.

Technically this is correct, since RUBY_TARGETS=ruby19 will be expanded automatically to the ruby_targets_ruby19 USE flag, but it is not a very practical or user-friendly solution. This is why we have decided to add ruby19 to RUBY_TARGETS now, so that things will work out of the box. The ¨downside¨ of this is that more people will get ruby 1.9 pulled in now, and that packages will be installed by default for both ruby 1.8 and ruby 1.9. This was our intention anyway, since it will make switching to ruby 1.9 as the default ruby implementation easier down the line.

Our recommended setup is to not specify anything yourself, so if you already added the USE flags or modified RUBY_TARGETS yourself, we recommend that you remove these again since the default should now work correctly again. By using the defaults you'll make it easier to keep things working out of the box in the future. Obviously, if you care in some way, you can make all these changes!

Our Ruby project page has also been updated to reflect the current status of the different ruby implementations in Gentoo.

Published on 25/05/2012 at 21h13 by Hans de Graaff, tags , ,

RUBY_TARGETS default now changed to include both ruby18 and ruby19

Contrary to my earlier post about ruby 1.9 going stable, we've decided to add ruby19 to the default RUBY_TARGETS now, rather than wait a few weeks. The main reason for this is that some packages correctly depend on dev-lang/ruby, and thus pull in ruby 1.9 now that it is stable, but they also pull in supporting packages that need to be installed for ruby 1.9. Without the ruby19 target portage will complain that it lacks the ruby_targets_ruby19 USE flag for these packages and it suggests to add them to package.use.

Technically this is correct, since RUBY_TARGETS=ruby19 will be expanded automatically to the ruby_targets_ruby19 USE flag, but it is not a very practical or user-friendly solution. This is why we have decided to add ruby19 to RUBY_TARGETS now, so that things will work out of the box. The ¨downside¨ of this is that more people will get ruby 1.9 pulled in now, and that packages will be installed by default for both ruby 1.8 and ruby 1.9. This was our intention anyway, since it will make switching to ruby 1.9 as the default ruby implementation easier down the line.

Our recommended setup is to not specify anything yourself, so if you already added the USE flags or modified RUBY_TARGETS yourself, we recommend that you remove these again since the default should now work correctly again. By using the defaults you'll make it easier to keep things working out of the box in the future. Obviously, if you care in some way, you can make all these changes!

Our Ruby project page has also been updated to reflect the current status of the different ruby implementations in Gentoo.

Published on 25/05/2012 at 21h13 by Hans de Graaff, tags , ,

Ruby 1.9 going stable

I've just added arches to bug 411507, asking for stabilization of ruby 1.9.3p125 and its associated packages. This has been a long time coming but it looks like all the pieces are now in place for this.

Note that this currently only makes a difference for packages that request dev-lang/ruby directly. We don't have many of those, and most should already have been checked for ruby 1.9 compatibility. All other packages use the RUBY_TARGETS mechanism, so unless you have modified this yourself you won't get ruby 1.9 packages for now. If you want to install packages for ruby 1.9 then you can add ruby19 to the RUBY_TARGETS variable in /etc/make.conf.

For now the default for this variable is still "ruby18". We will add ruby19 in a couple of weeks when ruby 1.9 is actually stable and when possible issues have been fixed. Once ruby18 is no longer supported upstream we will also switch our default ruby implementation to ruby 1.9 but currently we don't have a set date for that.

Published on 19/05/2012 at 09h10 by Hans de Graaff, tags , , , ,

Ruby 1.9 going stable

I've just added arches to bug 411507, asking for stabilization of ruby 1.9.3p125 and its associated packages. This has been a long time coming but it looks like all the pieces are now in place for this.

Note that this currently only makes a difference for packages that request dev-lang/ruby directly. We don't have many of those, and most should already have been checked for ruby 1.9 compatibility. All other packages use the RUBY_TARGETS mechanism, so unless you have modified this yourself you won't get ruby 1.9 packages for now. If you want to install packages for ruby 1.9 then you can add ruby19 to the RUBY_TARGETS variable in /etc/make.conf.

For now the default for this variable is still "ruby18". We will add ruby19 in a couple of weeks when ruby 1.9 is actually stable and when possible issues have been fixed. Once ruby18 is no longer supported upstream we will also switch our default ruby implementation to ruby 1.9 but currently we don't have a set date for that.

Published on 19/05/2012 at 09h10 by Hans de Graaff, tags , , , ,

Ruby 1.9 going stable

I've just added arches to bug 411507, asking for stabilization of ruby 1.9.3p125 and its associated packages. This has been a long time coming but it looks like all the pieces are now in place for this.

Note that this currently only makes a difference for packages that request dev-lang/ruby directly. We don't have many of those, and most should already have been checked for ruby 1.9 compatibility. All other packages use the RUBY_TARGETS mechanism, so unless you have modified this yourself you won't get ruby 1.9 packages for now. If you want to install packages for ruby 1.9 then you can add ruby19 to the RUBY_TARGETS variable in /etc/make.conf.

For now the default for this variable is still "ruby18". We will add ruby19 in a couple of weeks when ruby 1.9 is actually stable and when possible issues have been fixed. Once ruby18 is no longer supported upstream we will also switch our default ruby implementation to ruby 1.9 but currently we don't have a set date for that.

Published on 19/05/2012 at 09h10 by Hans de Graaff, tags , , , ,

Ruby 1.9 unmasked

Today I finally closed bug 203706, 4 years after it was initially opened. That means that you can now go and install ruby 1.9.3 without having to unmask the packages and associated use flag. It also means that we'll try to add the ruby19 flag, when possible, to new ebuilds as we add them. With ruby 1.8 no longer in maintenance starting June 2012 we can now work towards making ruby 1.9 the primary stable ruby implementation. At this point in time, though, we don't officially support running your whole system on ruby 1.9 yet.

Unless you take action yourself nothing will change for the moment. If you want to start installing your ruby packages also for ruby 1.9, then you must add ruby19 to your RUBY_TARGETS in /etc/make.conf.

RUBY_TARGETS="ruby18 ruby19"

Note that this will only work in the testing tree for the moment. If you find bugs, please report them or drop by in #gentoo-ruby.

Published on 28/12/2011 at 14h40 by Hans de Graaff, tags

Rubinius now available in Gentoo as the 5th ruby implementation

After a hiatus of more than 2 years Rubinius is back with Gentoo. Rubinius 1.2.4 got added this weeked as dev-lang/rubinius, making it the 5th ruby provider natively supported in Gentoo. If you want to install your ruby packages (also) for Rubinius you should add "rbx" to RUBY_TARGETS in /etc/make.conf. That will ensure that all packages that have been marked as ready for rubinius will be installed for it.

Right now that list is quite small still, but this should improve over time. If you would like to see a package marked for Rubinius (or another missing ruby implementation), then please open a bug for it. Please add the output of a successful build with both FEATURES=test and USE=doc to verify that everything works as expected.

Thanks to the people participating in bug 334177 for testing, initial ebuilds, and support.

Published on 23/10/2011 at 14h50 by Hans de Graaff, tags

Powered by Publify | Photo Startup stock photos