Re: Can we require build-arch/indep targets for lenny?
Steve Langasek <vorlon@debian.org> writes:
> 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
> maintainers.
The fix IS trivial. You can't tell me that it is a problem to add
"build-%: build" to your rules file when you are doing an upload
anyway.
Also by changing policy nothing becomes unbuildable as tools would not
yet take advantage of that policy. It just means it would be a bug not
to have the targets.
> 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
> involved.
I give you that. binNMUs would be a slight problem. The idea predates
binNMUs though so that was never discussed back then.
>> 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.
I don't consider that a big deal. We already don't take advantage of
them now. If the majority of packages update to the new standrds
version before lenny that is just fine.
> 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?
Because detecting has side effects and is costly, if it wrks reliable
at all. See other mails.
MfG
Goswin
Reply to: