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