So, finally Mark gave us GCC 4.5.0 to play with in the tree… obviously it’s still masked, as the tree is definitely not tested to work with it. But this is why I’m working on the tinderbox, isn’t it? After the ebuild was there, I prepared to start a new run from scratch to the tinderbox. What is a “new run from scratch”?
Well, the tinderbox usually works incrementally: not only it has a queue of packages to merge, but every time I sync, it resumes (more or less) from where it stopped. When the whole queue is consumed, a new list is generated of packages that haven’t been merged in the past six weeks, or that have been merged but have new versions (or revisions) in the tree, and that becomes the new queue.
A new from scratch run means that the tinderbox is cleared out: all the packages that are not part of the tree induced by the world and system sets are removed by the tinderbox, system and world are rebuilt, then a new list of all the rest of the packages… then it starts. It might sound easy and quick, but to unmerge 12000 packages (yes, twelve thousands!) it takes well over a day.
This by itself is a good test for unmerge actions, and it provides useful clues. For instance I know that a single unmerge of a bunch of texlive modules will take æons to complete, as it rebuilds the font cache after every unmerge. The same is true for the packages that update the MIME database, and to a lesser extent to Python modules. Having a way to deal with these things at once at the end would most likely help us here.
Now, I originally wanted to go on and implement the spec file trickery to check for flags (remember? this was one of the first reasons why I started working on the tinderbox), but at the end, I decided to leave that for another time. My reason for not going with that at the same time as GCC 4.5 is that… this time I’m going to get surprised: I sincerely have no idea which problems this GCC will produce, compared to the problems that could have been caused by GCC 4.4 which I had a good clue how to fix before starting.
Also, I’ve been pretty scared to the effects of GCC 4.5 on my host system: during the rebuild, GNU tar stopped working properly, so that, for instance, all the calls to libtoolize within the ebuilds failed as they weren’t able to update the config.sub and config.guess files. I worked this around in the middle of the merge by switching tar with bsdtar provided by libarchive, and all is working fine, for now. The tar failure has to get investigated though, obviously.
Anyway, the work has started, even though it’ll take a bit to roll out entirely — I hope you’ll enjoy the results. And if you feel like thanking me, there is the wishlist — too bad that I can’t put eBooks in that list (since I don’t use a Kindle).