On 04/12/2011 10:19 PM, Adrian Schröter wrote:
Am Dienstag, 12. April 2011, 21:54:56 schrieb Peter Linnell:
On 04/02/2011 09:51 PM, peer wrote:
On 04/02/2011 08:20 PM, Stephan Kleine wrote:
On Saturday April 2 2011 19:13:48 you wrote:
Here is the bug report
Well, it is obvious that the debian folks don´t care about anything outside their ivory tower. I meant filing a bug at the cdbs upstream that their build scripts are broken cause being unable to build in parallel _is_ a bug IMHO, so they would perhaps fix this.
Er, sry, I forgot what cdbs is, seems like you are screwed ;P
But more seriously, not doing the builds in parallel is just a waste of time and resources and debian& buntu builds already take much longer than rpm builds (e.g. during package install) so disabling parallel builds to please some broken packages isn't an option imho. Simply wait till a way to disable them in the packages meta data is implemented and fix it in the meantime by adding "-j1" to your make call.
You didn't read the reply by the author well. The package is not broken, it's a choice to have the package like it is. That's why it's not a accident that it fails on obs and not on the Debian, Ubuntu and Launchpad build systems. They doesn't violate the Debian policy and I think that's a good choice. That's also why the cdbs author argues that obs is broken, not the package and I do agree with him here.
It's fundamentally wrong imo to provide a service for Debian packages and not accept the Debian way and the Debian policy. Of course you could discuss the way of building with the Debian devs and try to convince them (at least the cdbs author seems to be open for a rational discussion). But at the end the best thing a service for Debian packages can do, it to adapt to the Debian way. Then we as users are assured that we don't need all kinds of hacks to get our Debian packages build.
I read the Debian policy carefully and nothing there it seems _prohibits_ parallel building.
Where is this set exactly ?
We can parse that maybe in build script and limit it to "n". Or take the dpkg tools already care of that ?