The Ruby NG saga continues

In the past episodes, I’ve started working on a new ruby eclass and that work got me pretty frustrated because Ruby on Rails packages are messed up and even though I was going on with fighting the fight so that Gentoo can become the best vendor to develop and deploy Ruby (and Rails) software on, there have been quite a few setbacks.

First of all, the complexity of the eclass grew a lot as I decided to split it in two: ruby-ng allows handling generic Ruby extensions, while ruby-fakegem allows creation of “fake” gem by installing the data like it would for gems. Unfortunately for the way I’ve been handling dependencies right now, this requires a double-inherit line, first for ruby-ng (to make ruby_samelib() visible) and then another for ruby-fakegem (to pick up the fake gem dependencies – I cannot just use RDEPEND/DEPEND normally because each gem will have, in its DEPEND, the gem’s runtime-dependencies, when built with the test USE flag enabled; but if there are further dependencies like eselect tools, just using RDEPEND wouldn’t be correct). Probably this is one of the things that will change with this week.

Now, one thing I’ve been asked privately is why am I doing such a huge effort with converting the ebuilds if it’s just a proof of concept and it wasn’t submitted to gentoo-dev for approval yet. Well, the main problem is that it’s always difficult to foresee what the use for an eclass will be. for instance when I designed the original autotools.eclass, while I did take into consideration a few packages I knew of, most other devs pointed out that their packages needed something slightly different; with time, autotools.eclass grew quite different from what I designed in a bored afternoon. The result of this is that I finally understand that an eclass cannot be just designed on paper, it has to be applied to real world use cases to work out well.

So even if the workload is quite high, I’m working with real ebuilds, with real and complex packages, with all their deptrees and so on. While it was certainly boring to rewrite almost thirty ebuilds yesterday when I decided to split ruby-fakegem out of ruby-ng, and it’ll be even more boring when I – almost surely – will have to change forty ebuilds for a change in the interface, it’s what saves us from having an eclass that is complex for no good reason. For instance one of the problems with the current ruby eclass is that it tries to take into consideration an absurd amount of configuration scripts used to build extensions. While of course the situation wasn’t this complex at the time it was written, the result now is an overcomplex eclass that tries to do way too much of things that we could do without, and doesn’t do lots of things we now need.

And if you wonder, no I’m not doing this as a job for any company; it’s out of my own free time, and during the breaks I get from the projects I’m paid to work on, I have near to no personal free time lately. I’m mostly fine with it, but given I know there are a few companies that will have a very good time once this all is in place, I wouldn’t disregard a literal “thank you” from time to time… without lacking respect to them, up to now they always come from single users, which is pretty nice… it’s just upsetting that while most of this work ends up helping companies, they don’t seem to care…

But the problems don’t stop at writing and improving the eclasses themselves: there are multiple problems with the underlying packages, because of upstream failures. Now I cannot blame upstream if a package that was last released in 2007 fails its tests with Ruby 1.9 or even worse with JRuby, but there are quite a few cases where the tests fail, on Ruby 1.9, with code released *last month*… especially Rails-related packages, and one case when the 2007-released package had broken tests (that passed) on Ruby 1.8, while the fix for Ruby 1.9 shown that.

But Ruby itself wasn’t without problems: when built with parallel make it can result in an unusable dl extension (the one that dynamically load a shared object from the system to bind, at runtime, specific libraries), which causes it to abort at runtime (yeah, it’s not an exception, it’s an abort of the process because there were missing symbols). Nor the way we as a team acted on Ruby 1.9 build failures was free from fault: we have never forced --no-undefined on the extensions’ builds, which would have caught the dl problem at build-time, as well as would have shown that the compiled extension of ruby-fcgi is not fully Ruby 1.9 compatible (this, too, is deemed to abort, instead of throwing an exception, at runtime).

Also, the list of packages that lack releases, or that have gems but not tarballs nor tags available, is still growing: echoe and treetop are the latest additions. Luckily, gemtoo is supposed on the long term, to address these cases; unfortunately I don’t have the luck of using it right now.

Some people criticized the Ruby/Rails community just for the porn-based talk from Aimonetti.. frankly, the main issue with the development community is far from being that; if it was that, it would have been a trivial social problem. Instead it’s a much more rooted technical problem: people don’t know what a release is! Which makes the work for packagers tremendously more difficult!

Please, try to release code properly: tag it, push both gem and tarball. And please run the testsuite with both Ruby 1.8 and Ruby 1.9, nowadays!