1 |
On Thu, Apr 11, 2013 at 11:53 AM, Rick "Zero_Chaos" Farina |
2 |
<zerochaos@g.o> wrote: |
3 |
>> Not sure this is the way to go. I'll have to think through the |
4 |
>> implications. Consider your stage1 build dies with some stupid tree |
5 |
>> breakage that you can fix in your portage snapshot and restart the |
6 |
>> stage build. This is going to cause your stage to rebuild everything. |
7 |
>> |
8 |
>> Wouldn't disabling the use of binary packages during the seed stage |
9 |
>> update fix this? |
10 |
>> |
11 |
>> |
12 |
> I'm not sure I'd call rebuilding it every time a "fix" when you just |
13 |
> rejected deleting the bad packages and rebuilding ONCE. |
14 |
|
15 |
I'm not sure what you mean. |
16 |
|
17 |
Updating the seed stage should only ever happen once. If that fails |
18 |
and you don't have binary packages to fall back to on restarting, I |
19 |
think that's an okay price to pay. Especially since it happens early |
20 |
enough in the process and avoids potential problems that are only |
21 |
noticed at the beginning of stage2. |
22 |
|
23 |
Oh, and if updating the seed stage fails... it was only rebuilding gcc |
24 |
dependencies anyway. That's not so bad at all. (I don't care about |
25 |
custom update commands and isn't something that we can fix) |
26 |
|
27 |
> As I said, the only proper fix is to update the toolchain to EAPI5. We |
28 |
> could live in the dark ages forever, but I really don't think it helps |
29 |
> anyone. |
30 |
|
31 |
That seems like a potentially good long term goal, but isn't something |
32 |
that we can force through. |