For those still pressing to have Ruby 1.9 available out of the box in Gentoo, the Ruby team is happy to announce that we’ve reached now the first step to get this done: re-keywording.
I’ve opened bug #332593 to ask arch teams to re-keyword Ruby 1.9, so that we don’t have to mass-drop keywords on the Ruby packages themselves. This is the first step toward the unmasking and thus the general availability of Ruby 1.9 for the masses. Now, while I have covered some questions before I’d like to answer a few more now, just to be on the safe side.
Why is package $foo asking me to downgrade rubygems? Your package is not ported to the new eclasses — in particular it’s still using the old gems.eclass that is now deprecated and should not be used at all. The way that old eclass works, it needs a hacked Rubygems that can work from within Portage; I’ve recently unhacked it so that it does not have that trick anymore, and rather follows upstream. We don’t use rubygems directly with the new eclasses so there is no need for it to have such hacks. If you’re on a stable system with some unstable packages, make sure to use the unstable version of the package requesting the old rubygems; if that doesn’t solve it, the package itself needs to get ported. In theory there shouldn’t be many more packages like that around. I’ll try to write soon on how to do that porting.
Why is 1.9.1 gone? Well, turns out that most of the code out there targeting 1.9 is mostly working with 1.9.2 as well as the previous 1.9.1; the porting is generally trivial and can even be worked around, and usually just hits tests, documentation building and – much more rarely – the build of the extension itself. For the rest, they are compatible enough that the trouble with the new version is bearable. And since it also solves a number of problems for us (with the layout it uses for installing on the filesystem), it’s a definitely better target.
When will Ruby 1.9 be unmasked? It’s not yet defined, but it still shouldn’t take too long; as I said before we haven’t covered yet all the problems, such as bundled bindings, Ruby-as-interpreter and other things like that. I’m not sure if we’ll cover all of them before the unmask to be honest, but we’ll have a plan before unmasking at least.
Can I set Ruby 1.9 as default interpreter? Can I simply use Ruby 1.9 without 1.8? Right now, Ruby 1.8 is still the officially supported default interpreter. That means that quite a bit of code will fail if you don’t have 1.8 installed, and some other will fail if ruby defaults to 1.9. As it happens, right now as well as once it’ll be unmasked, we’ll be accepting reports for packages failing with Ruby 1.9 installed, but not if it’s the sole installed or the one selected. You can report bugs with patches to fix problems with Ruby 1.9 selected (as long as the patch is clean and not a hack), and you’re asked to not report bugs if you don’t have 1.8 installed at all, unless you have a very good patch to solve the issue.
I know already that it’s a tricky situation, as all of us would prefer not to have to rely on using ruby19 for our scripts; this is why I have already talked about the need for making the ruby command be a smart wrapper, akin to the Python one, rather than a symlink. This way we can change the selected interpreted on the fly, and have a different one on a per-user basis. Doing so safely, though, is a bit tricky; nothing that can’t be done, but might require a bit more work than you’d expect. And right now, I’m swamped enough with job tasks that I cannot spend another unpaid day working on it. You know the drill.
Why does it want to install the same virtual package many times? I’ve started today implementing Ruby virtuals (virtual/ruby-*) slotted per implementation. This is a neat trick that allows keywords to be handled more easily, as each version keeps the most-stable keywords from the implementation it tracks, without use.mask and other tricks in the middle of it. As of today this only concerns ruby-ssl (which are the OpenSSL bindings for Ruby, provided by the ssl USE flags on MRI and REE, and by jruby-openssl for JRuby as the name states), but I’ll probably move the other virtuals to use the same idea in the next weeks.
With all the fuss about LDFLAGS why most compiled Ruby extensions ignore them? Actually, they aren’t ignoring LDFLAGS as much as respecting what Ruby itself tells them to use. For a long and boring story, the default for them is to use whatever Ruby was built with. It’s tricky to get around that as not all extensions use just those and there isn’t a very good way to solve it that I know. I’ll be working on finding a decent workaround, but it’s lower priority for now for me.
Why do you single out against Funtoo, rather than all the Gentoo-derivatives? Okay this I actually got asked only once and I’d like to point out what the problem is with Funtoo better. It really involves Ruby alone in this case; since Daniel not only wanted to have Ruby 1.9 available, but decided to change the Ruby naming scheme used by Gentoo; while we had ruby16, ruby18 and now ruby19, Funtoo uses ruby1.9.
That wouldn’t be a problem, if it wasn’t that the RUBY_TARGETS was designed to make use of the base name of the ruby interpreter – yes Ruby Enterprise has a different name, it wasn’t my call, but ree18 sounds better than rubyee18 when you have to actually use it, and mri18 wasn’t very easy to understand for most users – and expects Ruby 1.9 to be… ruby19.
So unless the Funtoo guys decide to go back to our naming scheme, they’ll have to patch our eclasses to add support for their non-standard installation. Good luck to them and their for keeping that up. For sure I’m not going to spend my free time to debug their issues as they called it up on themselves.
As usual, I have to remind you all that I’m working on Ruby mostly on my personal free time, so unless you do like Zeno and pay me to look into what you’re interested in, just complaining that we’re not good enough for your liking is not going to get you anywhere. On the other hand feel free to report problems if you find something that does not work as intended.
And as I noted, I’m happy to be paid for working on particular gems you’d like to see available in Portage under the quality assured by the Gentoo Ruby team (with Ruby 1.9 and Ruby Enterprise support if applicable).