Hi!
On Wed, 2011-03-02 at 03:59:43 -0600, Jonathan Nieder wrote:
> Did you read the rest of the message?
>
> But okay, I am willing to accept that this is an approach we do
> not want to use. Which still leaves us with a number of options.
>
> To help some existing packages today (and break others):
>
> 1. Find an active "make" maintainer.
> 2. Polish the patch in Bug#598534 and apply it.
> 3. Use
> make-first-existing-target build-arch build -- -f debian/rules
Well, I don't think make-first-existing-target belongs in the make
package (but then I'm not the make maintainer). It's clearly a hack,
but if we'd decide this is good enough, then I'd rather see this
supported natively by make itself, which would avoid side-effects
when running make twice (or more), otherwise it might make slightly
more sense to be bolted into dpkg-buildpackage instead.
> To help no existing packages today but make it easy for packages
> to opt in (and not break the others):
>
> 1. Introduce a Build-Options facility for packages to advertise
> capabilities like this.
> 2. Teach dpkg-buildpackage to honor it.
I don't think Build-Options/Build-Features is a good idea, as stated
previously on these bug reports. For example most of my packages
already support build-arch/build-indep, now I have to also state that
explicitly? Buh. :)
> To move towards a world in which all packages support build-arch and
> build-indep:
>
> 1. Teach dpkg-buildpackage a new switch to use those targets.
> The operator can easily figure out when they are available if
> building by hand.
> 2. Introduce a lintian test for build-arch/build-indep presence.
> 3. Contribute patches.
> 4. When there are not so many packages left without the feature,
> propose a mass bug-filing/release goal.
> 5. Finally, update policy and make autobuilders use the switch
> to use those targets when building unstable and experimental.
And I think we should just go ahead with a flag day and declare
build-arch/build-indep mandatory (at least for the cases were it makes
sense, see below). I'd even go further and combine that with
dpkg-buildpackage stopping to set compilation flags on the environment,
so we only have to deal once with possible mass FTBFS on the archive.
Also not all packages really need them:
* Source packages that only provide arch:any packages should not have
Build-Depends-Indep nor Build-Conflicts-Indep, so it should not
matter if build/binary targets are called directly (instead of
build-arch/binary-arch).
* Source packages that only provide arch:all packages might have
Build-Depends-Indep and Build-Conflicts-Indep, and because they
have to be satisfied anyway, it does not matter if build/binary
targets are called directly (instead of build-indep/binary-indep).
* They really only makes sense for source packages providing both
arch:any and arch:all packages.
This should reduce the affected packages.
regards,
guillem
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110606075525.gb16...@gaara.hadrons.org
