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.
Don’t the gem files still contain everything we need anyway? It’s easy to extract the files from them.
Not really that easy; most gems are tarballs, but not all of them. And sometimes they don’t contain _all_ that we need, Rakefiles often are missing iirc.
Fair point about the Rakefiles but I beg to differ on the gem format. Maybe some of them are tarballs but all the ones I currently have are cpio archives with a data.tar.gz and metadata.gz file instead. These are easy to handle.
Feel free to look at older stuff; there are gems that are base64-encoded bundles, there are tarballs, and maybe now cpio. The format is not stable enough to be easy to handle in Gentoo.
And what happen, if you completelly drop gem supporting, except rubygems? If the build/install phase of ruby moves current cflags/chost settings to place, where extconf.rb picks up (I don’t remember correctly, where is it), then we can build gems as same settings with portage, but without a portage’s pain.Yes, i know, it’sn’t a best solution – but i think there’s no best solution.
That’s _no_ solution at all; it’s just a way to not even look at solving the problem. It leaves your system at mercy of rubygems, which isn’t the most perfect software out there.The new ruby-ng eclasses _are_ a good solution, but requires collaboration from upstream devs. And not in the sense of them doing much more work, it just needs them to *do what they fsck they want but in a decent way*, like, you know, tagging their repositories.How is this more difficult than leaving users without coverage on the software they need to install?