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/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.
> even with some users complainingOf course breaking thinks during refactoring is not nice. But sometimes its the only reasonably way to go. Rather break some things a little with incremental refactoring, than makin a big bang. Because a big bang may be a huge headache in terms of merging and testing.A good example was the stabilization of KDE-4 which required breaking (some ~ at least) KDE-3.5 functionality. Sure you could have kept KDE-3.5 compatibility somehow — with an infinite amount of developer resources.I always say: in order to make a big change you have to break things. Otherwise you end up deadlocking yourself.
Unfortunately I just can’t consider KDE4 a good example, I am still missing a way to do pamphlet printing that works for me due to it.Maybe in most cases upstream can be convinced to use a nicer system?I guess quite often the language bindings will be by a one-time contributor and they might happily let you do changes in exchange for just keeping it working…