Re: Can we require build-arch/indep targets for lenny?
On Mon, Jun 18, 2007 at 10:30:55AM +0200, Goswin von Brederlow wrote:
> I would like to gather up some momentum for a policy change. Namely
> that the build-arch/indep targets in debian/rules become required
> instead of being optional.
> The reason for this is that dpkg-buildpackage can't reliable detect
> the existance of the build-arch/indep targets and must call 'build'
> instead. This forces every source to compile both architecture
> specific and architecture independent code on all buildds and
> increases the Build-Depends of packages a lot.
> Current status:
> I asked Lucas Nussbaum to rebuild all of debian with dpkg-buildpackage
> patched to call 'build-arch'. Here is the result:
> 7326 packages rebuilt (all packages not Architecture:all)
> 1727 built successfully
> 5463 failed to build with a "no rule to make" error.
> 136 failed for other reasons (unsat builddeps, etc)
> That means that only about 25% of debian package have a build-arch
> target. So there is still a long way to got.
> Possible upgrade paths:
> 1) Change policy now making 75% of package RC buggy instantly.
> This sounds horrible but the fix is trivial and there is still a
> long time to lenny to fix it.
No, the fix is not trivial; you will not get the buildd maintainers to
implement such a change when it makes 75% of the archive unbuildable, and
without such pressure you will never reach 100% adoption by package
Any serious adoption path needs to get used in the near term, to avoid the
package support for it atrophying due to disuse, while not breaking the
packages that have not yet implemented it.
> 2) Enforce the target for all new uploads and change policy once we
> exceed XX%.
> The unstable/experimental buildds could be patched to call
> 'build-arch' instead of build making any upload without
> 'build-arch' FTBFS. The security buildds would be left
> as is so nothing old breaks.
Again, very impractical, particularly for transitions where binNMUs are
> 3) Require 'build-arch/indep' with Standards-Version x.y.z
> Every source has a Standards-Version entry. dpkg-buildpackage could
> call 'build-arch' if the standards version is new enough and fall
> back to 'build' for older versions.
That's an option, but doesn't even let us take advantage of build-arch
support for existing packages that reference an older Standards-Version.
Whatever happened to the idea of using make options to check for the
existence of a target in debian/rules? IIRC we have a total of one package
in the archive that stubbornly refuses to comply with Policy 4.9
(debian/rules must be a makefile), so if we're entertaining solutions that
make existing packages buggy, why would we not use the method that minimizes
the number of packages that will be broken in the process?
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.