For a series of fortunate circumstances, since last week I’ve restarted packaging Ruby libraries, that I needed both for my own blog (Typo) and other stuff. As usual, I’m trying to avoid packaging gems since they can be quite of a pain in the bum to deal with. But since that’s something it’s known already I want to post a few more notes, especially in light of the fact we’ll hopefully be having a decent way to package gems in Gentoo by the end of the Summer.
Beside the fact that gems install lots of crap unconditionally (tests, examples, documentation, compiled object files, a copy of the original gem, …) and also brings in quite a few dependencies unconditionally (like rake, rspec and similar, which for us are only needed at build time), gems don’t run tests, which means there is no way for ebuilds to self-test the installed package to make sure it works; this actually did bite me with dev-ruby/aws-s3: the two latest 0.6 releases don’t pass tests at all. And I unfortunately have overseen it on dev-ruby/uuidtools, and now that I’ve investigated it, it turns out to be a bug in Ruby 1.8.7 .
What is interesting is that while the rubygems-based installs often bring in stuff like rake, rspec and other testing tools, most of the times they don’t get to require the packages that are only used for tests; I’ll use as example dev-ruby/sparklines that I just added to portage, which I based off Hans’s ebuild in his overlay (which used the gem). While the gem ebuild required dev-ruby/hoe at runtime, because that’s what the gemspec said, my ebuild only requests it at build time if either doc or test USE flags are enabled (because it’s required in the Rakefile itself), but at the same time, for testing it requires two more packages: dev-ruby/dust and dev-ruby/tidy_table (both of which I also added today).
Packaging the new stuff with fake gemspecs is, after all, not too bad, I think I can streamline it a bit more if I drop a few fields in the fake specs and then use generic replacements for the rest, but I’d rather avoid overdoing it since it’s just going to be a temporary solution.
And before you ask, no I’m not really keen on adding this stuff to an overlay for the only reason that I don’t intend on using overlays on the server where this blog is hosted, and since I’m packaging the Ruby code to put it to use from there rather than the original typo itself (see this repository for the public branches I’m using), Portage is where the packages belong.
So expect a few more packages in the dev-ruby/ category for the coming weeks.
