In my recent post about packaging ruby an user complained that we’re wasting time trying to get Ruby extensions to install through Portage, and that we should just leave the thing to gems.
Well, today for my “pleasure”, somebody found an interesting fact about gems: it does not check whether the installed binaries exist already or not, and always replace them, even if they are system binaries! You can see the details at bug #278566 if you’re interested.
So once again, gems is not perfect, not even close; it works if you need something dirty and quick, but on the long run is not something I’d like to use, and indeed this server does not use gems outside of portage at all, this very Typo instance is running with Portage packages (I’ve added calendar_date_select yesterday so I could upgrade to the latest version that has much less bundled libraries), and it’s working very fine.
And this is why I would like for the people who do maintain, as a job, Gentoo servers running Rails applications, to help, at least with comments and tests, the ruby-ng eclasses from this repository so that we can get them rolling. (Code and monetary contributions are also welcome of course, as are gifts).
As you might have guessed already, Portage would never overwrite system binaries, collision protection has been added a long time ago, and of course all the packages in Portage gets doublechecked before being okayed by our developers, while gems deployment is, as far as I can tell, mostly an automatic process. Of course that also means that there is an higher delay for packages to come into the tree, but there is a reason why that delay is there!
Update: as Alex just pointed me out, the same issue happened in 2007 and Debian already coped with it without warning the rest of us. Now this does say a lot about the security track of gems, since the same issue came back again, and Distributions need to make their own changes because gems don’t seem to accept that stuff is different for non-system package managers.
