After I turned it off I got quite a few people asking what’s going to happen to the tinderbox. I finally decided to turn it back on a week or so ago, since I started having trouble with new packages on my system and they were worth the hassle. I’m still not sure how to handle this on the long run to be honest: there are many costs tied to the tinderbox as I pondered and I’m not happy with having to keep paying for them myself.
On the other hand I have no time to either figure out how to get the Foundation to pay for tinderboxes, and even less to find a way to analyse the huge amount of logs provided by the tinderbox remotely. So unless somebody can help me with solving these problems, the tinderbox will only exist for as long as I wish to keep it going.
Putting these management problems aside, the tinderbox is now going through a rough patch mostly because EAPI=2 USE-dependencies started to find their way into the tree: even stuff that was previously ignored by built_with_use is now added as a dependency without trouble, and the results are, well, not excessively nice for what concerns the tinderbox. While it’s definitely better for the user to know of the needs and dependencies of the packages they merge before starting a long and boring build, in the case of the tinderbox, where as many packages are installed together as possible, it becomes troublesome to make all the dependencies fit.
Let’s not even talk about the = misplaced dependencies (if you need a given feature enabled on a library to have the same feature enabled, it usually doesn’t mean that the library has to have it disabled for you to have it disabled), and let’s just consider two prominent examples: Tcl’s and Perl’s support for multi-threading. Depending on whether the package makes use of threads, or is not multithread safe, the dependencies on the interpreter itself will require the USE flag to be either enabled or disabled. Since a package cannot be both multi-threaded and not, I’m forced to make a decision, which simply is to enable threads for both (it seems like they have the most dependencies this way).
Interestingly, most of the packages wanting single-threaded Perl, have optional Perl support, which means that to solve the conundrum I only have to disable the perl USE flag for those packages.
What might be of interest here, just for the news, is that just to satisfy the dependencies of USE flags, with the default profile and almost no global USE flag set (I enabled ruby globally, which is not enabled by default, and java5/java6 as I’m using Icedtea as global VM), I have 178 lines of package.use file. Plus 37 lines dedicated at enabling options for those packages that need at least one enabled (although some might be redundant right now because I filed bugs for them and they were fixed).
Further tweaks that are present in the configuration right now include having a longish list of masked packages as they need me to register (and sometimes pay as well) to get the distfiles (and they seem to be mostly scientific packages), or that need a CD-Rom (although they are now mostly solved by PROPERTIES=interactive), and finally for packages that block each other (which is baaad).
Sigh I wonder if we’ll be able to skip over all these problems at some point in the future, although I’m pretty sure that for the big part the problem lies in the way most upstream work: ignoring the fact that there is other software they don’t use out there.