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