Yes I’m quoting this historic episode even though it’s not from TNG at all; on the other hand, I remembered it when I watched the latest film; I guess date-long fans have to thank Roberto Orci for the continuous cameos of old canon content.
So we’re (very slowly) porting Ruby ebuilds to the new eclasses – as I’ve detailed before – even with some users complaining about it. Thankfully, the results start already to appear, as we’ve been able to address a number of problems upstream, including gemcutter’s tests missing entirely from the distributed packages, and just today the missing tagging of RedCloth’s repository (although I have yet to make a new ebuild using that).
But today, while running all the Perl packages through the Tinderbox (to test the feasibility of Perl 5.10 unmasking — yes it’s quite feasible, just eight out of around 1500 packages failed), I did come through one very nasty problem that I haven’t thought about before: bundled bindings.
While I have already ranted about it last year, a lot of packages still distribute their foreign language bindings (Ruby, Python, Perl, you name it) together with the main package where the code is. This is not only boring for packagers and users that have to rebuild – or retest – the same bindings even though there is no change), but also because in this case it creates quite some complexity for us to solve.
In the normal case of bindings shipped as gems, or as generic Ruby extension tarballs, the new eclasses work as a charm, as it can be shown by the ebuilds that we already have (dev-ruby/pg, dev-ruby/mysql-ruby, dev-ruby/sqlite3-ruby, …). The sources will be copied, configured, compiled, and the results installed for each Ruby implementation available. One after the other.
The problem that arises with bundled bindings, for instance obexftp’s bindings, is that we cannot feasibly run the copy/configure/compile/install step for the whole package two or three times. So you either limit yourself at exactly one implementation (Ruby 1.8) or you’ve got to come out with a different method to handle it.
The only solution I can think of right now is one that is not going to be liked by most developers: split the package in two: from one side you build your normal package, from the other you build only the Ruby bindings. Unfortunately this will most likely require a bit of fiddling around; if the package uses extconf.rb anyway to build the bindings, we hit the jackpot as we can run it like it was a separated package — and most likely we can also build it from within the original ebuild, with slightly hackish methods. On the other hand if it’s built with automake directly, it’s unlikely that it’ll support building just the bindings linking against the system library (unless it’s a single package of external bindings).
If we’ve got to split packages away, we’re definitely going to have in front of us a lot of pain: it means twice the bumping, twice the patching, twice the testing, and that’s not something fun at all.