Re: Bug#229357: Can we require build-arch/indep targets for lenny?

[Frank Lichtenheld <djpig@debian.org>]

On Fri, Oct 12, 2007 at 02:13:49PM -0700, Steve Langasek wrote:
> On Fri, Oct 12, 2007 at 10:49:13PM +0200, Frank Lichtenheld wrote:
> > No answer? I would like to work on this, but someone would need to
> > answer my questions about it...
> 
> > (explicetly sending to vorlon, too, ignoring the M-F-T)
> 
> I have no answers for you about whether there are defined semantics for this
> use of make. :)
> 
> Anyway, I thought this patch was ruled out in later discussion in the
> thread.

Hmm, it was opposed by some but I don't see a consensus reached
anywhere. Let's try to give a summary of the discussion.

So far the proposed solutions for this problem are:

1) Build-Options field

As pointed out this doesn't scale very well and there is no real way to
make it default behaviour one day. This would be the way to go though if
it only needs to be specified for few packages (either because we think
that few packages actually need build-arch support or because of the
solution I propose below, combining it with autodetection).

I'm not particulary impressed with this.

2) Standards-Version, i.e. make it 'must' in policy

This should work but it completly contradicts the past Debian standards
process (according to Lucas' numbers, the new policy would currently
only be satisfied by < 2000 packages, i.e. somewhere in the 20% region)
and would make a solution dependant on the policy team, which is currently
somewhat MIA...

It would be really nice to have a policy someday that acutally matches
reality, though.

3) Autodetection

Would be clearly the easiest solution if it works reliably.
There are some problems:
 - Works only with GNU make
 - depends on a _should_ in policy, not a _must_
   (error code)
On the other hand, according to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357#172 it
mostly works, and most of the cases where it doesn't work seem
to be the packages fault (i.e. the binary-arch target seems to
depend on the build-indep target without actually declaring
that dependency).


BTW, the "correct" solution in any case would be to run checkbuilddeps
again if we don't find build-arch support, since we need b-d-i, too.
And *poof*, there go our buildds ;) which brings me to the last
solution which I think wasn't actually proposed:

4) Adapt policy to sbuilds behaviour

I.e. don't require b-d-i on build, but only on binary and binary-indep.



Conclusion:

I would be interested to gather some input from the interested persons
regarding their exact position. I think the following questions should
give us a good understanding or their position:
(want == 'I want it and I also think it would be possible to do')

 1) Do you want to change sbuild to actually respect policy?
 1a) (SKIP if 'no' to 1) Before lenny's release?
 2) (SKIP if 'yes' to 1) Do you want to change policy to declare sbuild's
    behaviour official?
 3) Do you want for all packages to support build-arch in the
    nearer future (longest lenny+1) [== policy 'must']?
 4) (SKIP if 'yes' to 3) In the farer future?
 5) Do you think autodetection can work and should be used?
 6) (SKIP if 'yes' to 5) Do you think that autodetection can
    work and should be used, if packages would have the ability
    to override it if they know they get detected wrong?

My answers are:
YN-NNNY

After considering all the arguments I believe that the best solution
would be to try to implement autodetection _and_ support Build-Options
to give maintainers the ability to override it. Build-Options is simply
the easiest and best-working possibility, but for good behaving packages
it should not be neccessary. And I strongly believe that after lenny's
release dpkg-buildpackage should start to check the 'correct'
build-dependencies according to policy (i.e. requiring b-d-i if
build-arch is not supported).

I would volunteer to implement the solution I propose (in the near
future) if there are enough supporters.

Gruesse,
-- 
Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/