"Mark Knecht" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 07 Mar 2008 09:21:51 -0800:
> I'm not finding confcache or anything that's the obvious right choice on > that one. I'll emerge ccache though. Yeah... confcache was an experiment that has been shelved for the time being. It was designed to cache the results of various config tests repeated for many/most ebuilds, only dumping the cache and letting them retest from scratch when required (if something in the build system, say gcc or whatever, changed). The problem was that a number of packages put bad data in the cache/database, but compiled fine themselves, thereby leaving the bad data to be found by the next package that tried a test with the same data. Since this might be the first package after or the 100th, it was difficult to figure out where the bad data was coming from in ordered to fix it. The result was basically packages failing because they got a bad config, with no easy way to trace it, so they just masked confcache. Advanced users can still use it if they want, using package.unmask (they may need to find an ebuild too, as I'm not sure whether it's still in portage but masked, or not even there now, but it's available in the archives if necessary), but they have to be prepared to manually dump the confcache database and try again if problems appear. I ran it for awhile, but after my upgrade to dual dual-cores, decided the machine was fast enough at running the configs that it wasn't worth the hassle any more, so I turned off the feature and unmerged the confcache package. For people who'd prefer to have portage "just work" with the least hassle, even if it takes a bit longer on some packages, confcache is definitely something you want to leave alone, at least for now. Maybe someday... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- [email protected] mailing list
