On 12/11/2015 10:48, Jörg Schaible wrote: > Alan McKinnon wrote: > >> On 12/11/2015 10:29, Jörg Schaible wrote: >>> Alan McKinnon wrote: >>> >>>> On 11/11/2015 21:35, Walter Dnes wrote: >>>>> Ongoing installation. I looked at 2 instances of >>>>> "emerge -pv x11-base/xorg-server" and the order was somewhat different. >>>>> Here are a couple of outputs, just a few seconds apart. Is this a bug >>>>> or a feature? See attachments. >>>>> >>>> >>>> >>>> Emerge order is not deterministic, especially with parallel builds. The >>>> reason is that it does not need to be according to the dep graph - if >>>> two packages are at the same level and do not depend on each other, then >>>> the order they are built in does not affect the final result. >>>> Practically all parallel processing works this way. >>>> >>>> What is deterministic, is that if you build the same set of packages >>>> twice and even if portage does them in different order, the binaries >>>> produced are functionally identical >>> >>> Hmmm. And how can you then ever use >>> >>> emerge --resume --skip-fist >>> >>> if not even the first build is deterministic? I skip the first package >>> anyway only if the problematic package is the first one to build after >>> resume, but if I cannot even rely on that? >> >> >> Because it re-uses the previous build order, not re-generate a new one. > > That's simply not true. Emerge resume calculates the order again and for me > it starts often with a different package.
I've never noticed that. For me --skip-first has always skipped the correct first package (the one that previously failed). As long as a known build failure is not in the --resume list, I don't care what the build order is because it is irrelevant. The only time it becomes relevant is when an ebuild has a bug such as a missing dep. But that's a bug in the ebuild and is fixed there. -- Alan McKinnon alan.mckin...@gmail.com
