On Thu, Apr 11, 2013 at 11:22:54AM -0700, Matt Turner wrote: > On Thu, Apr 11, 2013 at 10:09 AM, W. Trevor King wrote: > > In order to avoid problems like this, it's probably a > > good idea to remove all the cached stuff with something like [1]: > > > > $ rm -rf --one-file-system /var/tmp/catalyst/{kerncache,packages,tmp} > > > > before building your stage1. > > Not sure this is the way to go. I'll have to think through the > implications. Consider your stage1 build dies with some stupid tree > breakage that you can fix in your portage snapshot and restart the > stage build. This is going to cause your stage to rebuild everything. There shouldn't be a need to clear the caches unless you've changed the specs or sources. Presumably you had to change something to fix whatever killed stage1. If that was an ebuild problem, it's unlikely that your fix changed an ABI without also changing the package version and you should be ok keeping the old binary packages. > Wouldn't disabling the use of binary packages during the seed stage > update fix this? Disabling creation of binary packages during the seed stage update would help, and disabling the use of binary packages during the stage1 build would help. However, what if you have built a binary package for GCC and then you update your tree to something that builds libmpc.so.3. In this case, you're in trouble if you use your old GCC binary packages anywhere based on the new tree. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy