Well, we know smp_flags lead to undeterministic builds that lead to
o uncomparable build logs
o difficult to trace bugs in the the build output
o undeterministic triggering of build system bugs
I had vtk  in the queue for a year, and one of the reviewers'
demand was to add smp_flags, since "it worked that well". I added this
for the sake of getting it reviewed and once the package was reviewed
it wouldn't build on Fedora builders. And it was quite
non-reproducible on my 4-way system, probably due to different number
of make threads, different timings etc. It was also non-reproducable
on the Fedora builders - it would fail but at different build stages,
so I started to check what BR changed between invocations and the
The benefits of smp_flags is that some very big builds are taking less
time. So if say openoffice uses them (I have no idea) it would make no
sense to forbid them for these packages. But for most packages that
usually build under 15 minutes on a serial invocation the drawbacks
are higher than the benefits (like package rebuilds simply breaking
for no apparent reason like vtk did).
But as *recommendation* we should switch from endorsing it to
questioning it and recommending not to use it.
Axel.Thimm at ATrpms.net