On 03/20/2012 11:58 AM, Brendan Conoboy wrote:
On 03/20/2012 08:24 AM, Jakub Jelinek wrote:
> I think the speed of the build hardware should be also part of the criteria,
> as all primary architectures are built synchronously. GCC on x86_64/i686
> currently builds often in 2 hours, sometimes in 4 hours if a slower or more
> busy box is chosen, but on ARM it regularly builds 2 days. That is a slow
> down factor of 12x-24x, guess for other larger packages it is similar.
Our current build systems can turn GCC 4.7 around in about 24 hours.
The enterprise hardware we anticipate using will take that down to
about 12 hours. If speed of build hardware is a consideration, where
do you draw the line? No secondary arch is going to get to the speed
of x86_64 in the foreseeable future, so it's effectively a way to
keep PA an exclusive x86 club.
I think the real question is, for the developers of on devel-list,
how will longer builds for one arch than another affect your
workflow? If builds on two architectures start at the same time, but
one takes longer to finish than the other, how will that impact you?
Right now you'll still be able to see and use the results of the
faster build before the slower build completes, so are you materially
You're on the right track here, but you need to consider not just builds,
but also updates. It's important for several reasons - an excessively long
compile time means it's less likely that an update will be filed immediately
after the build, for example. It's also important to consider things like
incident response. For example, it's not as if we've never had a CVE filed
against GCC that required rebuilding of packages. If it takes 24 hours to
build gcc (a number I just made up for illustrative purposes), then you've
got a scenario like where we're waiting on a build of gcc to get a libpng
fix out so that firefox isn't being exploited. And sure, you're thinking
"but who wants to run firefox on 32-bit arm?", but it doesn't matter,
because it's being exploited for an extra day on x86 as well while we're
waiting for libpng to be built with a newer compiler that isn't even in
That's the nightmare scenario, admittedly, but it still bears consideration.