| 1 |
Alan McKinnon wrote: |
| 2 |
|
| 3 |
> On 12/11/2015 10:29, Jörg Schaible wrote: |
| 4 |
>> Alan McKinnon wrote: |
| 5 |
>> |
| 6 |
>>> On 11/11/2015 21:35, Walter Dnes wrote: |
| 7 |
>>>> Ongoing installation. I looked at 2 instances of |
| 8 |
>>>> "emerge -pv x11-base/xorg-server" and the order was somewhat different. |
| 9 |
>>>> Here are a couple of outputs, just a few seconds apart. Is this a bug |
| 10 |
>>>> or a feature? See attachments. |
| 11 |
>>>> |
| 12 |
>>> |
| 13 |
>>> |
| 14 |
>>> Emerge order is not deterministic, especially with parallel builds. The |
| 15 |
>>> reason is that it does not need to be according to the dep graph - if |
| 16 |
>>> two packages are at the same level and do not depend on each other, then |
| 17 |
>>> the order they are built in does not affect the final result. |
| 18 |
>>> Practically all parallel processing works this way. |
| 19 |
>>> |
| 20 |
>>> What is deterministic, is that if you build the same set of packages |
| 21 |
>>> twice and even if portage does them in different order, the binaries |
| 22 |
>>> produced are functionally identical |
| 23 |
>> |
| 24 |
>> Hmmm. And how can you then ever use |
| 25 |
>> |
| 26 |
>> emerge --resume --skip-fist |
| 27 |
>> |
| 28 |
>> if not even the first build is deterministic? I skip the first package |
| 29 |
>> anyway only if the problematic package is the first one to build after |
| 30 |
>> resume, but if I cannot even rely on that? |
| 31 |
> |
| 32 |
> |
| 33 |
> Because it re-uses the previous build order, not re-generate a new one. |
| 34 |
|
| 35 |
That's simply not true. Emerge resume calculates the order again and for me |
| 36 |
it starts often with a different package. |
| 37 |
|
| 38 |
Cheers, |
| 39 |
Jörg |
Archives