On Sat, 13 Oct 2007, Frank Lichtenheld wrote: > 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).
IMO combining Build-Options and Standards-Version could be enough to get the best of both worlds. Use Build-Options to declare that the package supports some "should" rules of the policy but also auto-set some flags based on the version of the policy: if it's greater than the version which changed a rule in a "must", then we define the corresponding flag. That way maintainers don't have to carry dozen of options indefinitely. > 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? Yes. > 1a) (SKIP if 'no' to 1) Before lenny's release? I don't mind. > 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? I think it makes sense in the long term, yes. > 5) Do you think autodetection can work and should be used? I must say I'm not very convinced by the various tricks tried and suggested. That said I wouldn't oppose all of them either. > 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? Seems reasonable, but you still have to let them declare if they support the target build-arch if they declare "skip-auto-detection". :-) So basically the process would be: - if Build-Options contains build-arch, call build-arch/indep - unless Build-Options contains "skip-auto-detection" (or whatever name we come by), do an auto-detection and call build-arch/indep - otherwise you have to call "build" > 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. Ack from me at least. It's time to take a decision here. First step is to add the Build-Options support IMO. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/
