As you might know, among other things I’m in the Gentoo Ruby team and I take care of a few sparse packages. I’ve started working on the new ruby eclasses because, beside liking Ruby as a language, one of the tasks I had for my job (which is now running out, and soon won’t be any longer) required me to use some extensions that weren’t packages for Gentoo at all.
After some time, I resumed yesterday working on that particular project, and a few more dependencies were added, which I went packaging; to package these, it really reminded me why packaging Ruby extensions in Gentoo is so difficult, so for reference I’m actually writing it down here.
The main problem is that we shouldn’t package gems not because, like Debian, we don’t like the layout alone, but also because they don’t comply with our packaging phases, including testing, that allows our packages to be what they are on the system (the best integration). Indeed, while we can package gems somehow, doing that we have a few drawbacks:
- the content of the gem is installed unconditionally; which means we install more than we should, like tests;
- the gem itself get installed in the so-called cache, which means it also is wasting more space on disk;
- installation for multiple Ruby implementations will duplicate even more content;
- tests are not run during ebuild phase, so it’s very difficult to make sure that the installed code is properly handled;
- documentation doesn’t get installed in our specific documentation system;
The main problem of this is, obviously, the missing test phase: test phases are designed to make sure that the package is fine and all its dependencies are present, dropping them are a huge problem (indeed I identified more than a couple of packages that only with failing testsuite shown that they are broken by --as-needed build).
But the problem does not stop at this; to not package gems, we need to make use of tarballs; unfortunately most Ruby extension projects lately decided that making tarballs is not trendy enough, and they just release gems; this wouldn’t be a terrible problem, if they tagged their sources in their repositories, whatever they are, but that’s also getting old it seems. Actually, our best ally on this matter has become github; since they fixed their problem with downloads and EAPI 2 introduced the redirected naming for downloads, downloading tagged tarballs is quite easy and fast; when the project tags releases at least.
Indeed, the tagging does seem to be quite hectic between projects, sometimes I’m quite sure they are mistakes (git tags not pushed), some other times there is a systemic lack of tagging that is quite a problem. And to solve that the best option I have is usually to just make a snapshot of the thing; again github helped here when I had to package ttfunk and pdf-inspector yesterday.
It really would be quite simpler if projects consistently tagged their releases, and used a public source control manager that allowed to download an arbitrary tag. But I guess I won’t be counting on this for quite a while.