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.
I think that use dependencies should be handled automatically by portage. Current solution that user needs to alter use flags manually in package.use file is not very good. It is like putting a package dependencies into world file by hand.
hs: how does portage know which flags to use?Flameeyes: The tinderbox could be set instead of all …to say all packages one would want; instead to a ‘profile’ a set of default packages used. For instance..host and hosted for vps and any webservices?More or less running development tests for all of ‘host’ packages for the individual profiles. I know it doesn’t take into account say ‘all’ collisions; but could be more modular and of good benefit.I always thought this too large an expense for you alone.
further say calculating backward for each individual ‘use’ say … glade-development profile or kde-desktop. ‘system’ ‘gcc-tools’ and pulling in all possible ‘needs’ then running tests instead of the whole tree should increase the individual profiles at less cost? An individual machine could then run each ‘usage’?
user99: If package “foo” depends on package “bar” with “kde” use flag (bar[kde]) then portage has to turn on “kde” flag for “bar” to satisfy dependency requirement.
@HS: Portage already supports that to an extent; I know Zac is working to make it much more prominent, but at the same time, the way the tinderbox works I *do* need the manual tweaking to avoid two packages forcing Perl to be once threaded and once not: in that case it would always invalidate Perl’s modules and I would find myself screwed.@user99: I’d rather keep the tinderbox slow and comprehensive; most of the things that it can find are in packages that are not very often used, and are still lingering in the tree. They might not sound too appealing to get fixed, but they _are_ a burden for Gentoo as a whole unless they are properly fixed.On a different note, scarabeus proposed me to drop the kde-base category which should be very well tested already; unfortunately the tinderbox is designed to identify unexpected interactions as well, so dropping that will drop the chances for some package to have (unexpected and broken) KDE interactions, such as “automagic dependencies”:http://www.gentoo.org/proj/… which would have to be fixed.