While I haven’t been able to write enough documentation, or to submit all my custom checks to Portage to be merged in (and some stuff is pretty heavy-load that you probably don’t want on your standard Portage system), I’d still like to document my approach for the tinderbox to let others learn from it; and to explain why it’s not really the straight process that many thinks it to be.
Patrick has already blogged in the past about the problems faced by his approach; mine has pretty much the same problems, but given I execute it on my desktop system, it makes it much easier to identify and correct the issues before they become truly obnoxious. They still don’t look good though, to be honest.
Also, some of the problems I also blogged already, like for instance the problem with packages needing one default backend that stops my efforts as they require me to manually set in the USE flags they need.
The first problem appears with packages not respecting the CC settings that can easily ignore ccache altogether. While some people don’t understand why I use ccache after what I said I should point out some details about the tinderbox to make it understandable. The tinderbox was not designed as much as forged up, so it’s quite naïve in its approach; in particular it does not discern between a package that fails to build and one that couldn’t merge and one that wasn’t tested yet. They all are in the new list the next time I run the script to find what needs to be built.
For this reason, leaf packages that fail to build may pass more than once through the tinderbox, so the ccache can help speeding up the rebuilds. But even more importantly, non-leaf packages like asterisk or boost that fail to build many times in a single tinderbox run won’t rebuild everything all at once, and the same applies to non-leaf packages that fail to merge because of collisions or those that get removed and re-added by blockers.
Another nasty issue I face is when the testsuites (or the configure tests!) freeze up; if this happens while I’m at the computer, I’d notice (since switching desktops with compiz allows me to see whether it’s building or not), but if that happens while I’m sleeping (as rare as that seems to be happening lately – me to sleep, not the tinderbox to freeze), it can easily remain stuck for hours, like it happened last night with dev-libs/ace that was stuck in ./configure for over four hours (it would have been seven if they didn’t wake me up but that’s another story). Unfortunately it’s difficult to tell when a build (or a testsuite) is just slow or completely stuck.
Finally there are problems with the unknown and untested interaction between different packages; with method I’m using, opposite to what Patrick does, all the packages get to interact with an “insubordinate” system which may have conflictual software installed, and cause automagic dependencies to trigger, which in turn can cause packages either to compile improperly or to fail. I think one of the thing that gave me more headaches about this was a (maybe still present, I don’t really know) automagic dependency of gnustep over mDNSresponder.
More work is needed, a lot more work, to get the tree in a state that can be called “clean”. Maybe by the end of the year?
