1 |
Alan McKinnon wrote: |
2 |
|
3 |
> On 12/11/2015 10:48, Jörg Schaible wrote: |
4 |
>> Alan McKinnon wrote: |
5 |
>> |
6 |
>>> On 12/11/2015 10:29, Jörg Schaible wrote: |
7 |
>>>> Alan McKinnon wrote: |
8 |
|
9 |
[snip] |
10 |
|
11 |
>>>> Hmmm. And how can you then ever use |
12 |
>>>> |
13 |
>>>> emerge --resume --skip-fist |
14 |
>>>> |
15 |
>>>> if not even the first build is deterministic? I skip the first package |
16 |
>>>> anyway only if the problematic package is the first one to build after |
17 |
>>>> resume, but if I cannot even rely on that? |
18 |
>>> |
19 |
>>> |
20 |
>>> Because it re-uses the previous build order, not re-generate a new one. |
21 |
>> |
22 |
>> That's simply not true. Emerge resume calculates the order again and for |
23 |
>> me it starts often with a different package. |
24 |
> |
25 |
> I've never noticed that. For me --skip-first has always skipped the |
26 |
> correct first package (the one that previously failed). |
27 |
|
28 |
That's what I always did originally also, until my build suddenly broke at |
29 |
the same package again and I had to notice that it skipped a completely |
30 |
different. |
31 |
|
32 |
> As long as a known build failure is not in the --resume list, I don't |
33 |
> care what the build order is because it is irrelevant. The only time it |
34 |
> becomes relevant is when an ebuild has a bug such as a missing dep. But |
35 |
> that's a bug in the ebuild and is fixed there. |
36 |
|
37 |
Well, normally I don't care about the sequence either, except when skipping |
38 |
the first ;-) |
39 |
|
40 |
Cheers, |
41 |
Jörg |