Re: [gentoo-user] Re: Re: Emerge order not deterministic !?
On Thu, 12 Nov 2015 09:48:48 +0100, Jörg Schaible wrote: >> > 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. Then use emerge --keep-going and portage will take care of skipping failing merges for you. -- Neil Bothwick Every morning is the dawn of a new error... pgp5Vahc6BWYX.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Re: Emerge order not deterministic !?
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. Cheers, Jörg
Re: [gentoo-user] Re: Re: Emerge order not deterministic !?
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
