Currently, Debian Policy doesn't match with the current practice in section 7.7. > The Build-Depends-Indep and Build-Conflicts-Indep fields must be > satisfied when any of the following targets is invoked: build, > build-indep, binary and binary-indep. I know that people like to say that Policy should reflect reality, not have wishful thinking (like in #178809). It's been tried before but I'd like to try again to get a transition done to make reality into what 7.7 says it is. As it stands, buildds call "debian/rules build" without having B-D-I installed, contrary to 7.7. Buildds do call "debian/rules binary-arch". As such, B-D-I does what it's supposed to do on buildds only in conjunction with binary-arch and clean targets. Obviously, we'd get half of the archive FTBFS if we made buildds call build-arch instead of build now, since it's an optional feature. Having a call to "debian/rules build-arch" fail tells us less than we'd like, too. Nobody's yet written a reliable check to see if the build-arch target is present in a debian/rules file. I'm hoping that we're only dealing with debian/rules files that are makefiles. It'd be desirable to know if build-arch is supported from the .dsc file alone, without unpacking the source package. This has been discussed before and I'll list some options from the top of my head. I'm hoping to start a discussion, again. Now, option 1 (cold turkey): Make build-arch to be a mandatory target in debian/rules files in the next policy version (3.9.0, already?). Any existing "build" targets work, by necessity, correctly without having B-D-I installed, and a debian/rules file could be fixed by adding one line: build-arch: build Buildds would still call "debian/rules build" on anything that had a smaller Standards-Version than 3.9.0, and "debian/rules build-arch" on the rest. It'd be the maintainer's responsibility to check that it works before bumping the version. Option 2 (features field): Add a field called "Build-Features:" to debian/control and have it contain a space separated list of tokens. Define "build-arch" as a recognized value. Put that in .dsc. As with things like this, we'd potentially get stuck with it forever, but it'd be the least invasive thing to do and still get buildds to use build-arch. There'd be no transition, other than getting sbuild patched. We could also change build-arch into a "should" feature and warn anyone who didn't support build-arch and switch over to having it as a "must" once everyone did it. It'd be easy to check for that, with this. Option 3 (lintian hackery first): I know some people would like to see a lintian check, first. The thing is, debian/rules is a program, so trying to figure out any properties about it, like "does it support feature X?" or "does it halt?" gets quite close to the halting problem. GNU make does have some options to query a makefile, like --dry-run and --question. Even those would require evaluating a makefile, at least to some degree. If someone put $(shell rm *) in there, it'd do that. I'd like to see something like "Running debian/rules --dry-run or --question must not have harmful side effects or affect any subsequent calls to debian/rules." in the policy before relying on those. I'm hoping that there's nothing controversial about this addition. IMHO it's a rather pathological makefile that does things like that. I'd like to see some explicit option added to make that would just answer the question "Is there a rule that would match target X?". Same considerations about evaluation would apply as to -n and -q. As it stands, I'd need to do something like this: debian/rules -q build-arch 2>&1 >/dev/null | tail -n 1 | \ egrep -e '^make: \*\*\* No rule to make target `build-arch.\. Stop\.$' As an aside, guaranteeing that --dry-run wouldn't do anything evil would help lintian in other matters, too. For example, this is what the current version does to check whether a package uses CDBS: if (m,^include\s+/usr/share/cdbs/1/rules/debhelper.mk,) I'd rather run "debian/rules -nds" to check if it includes something from under /usr/share/cdbs/. Option 4 (give up): Remove the mention of "build" from 7.7. Policy would match the current usage, right then. This is not what I'd like to see, since I think that a reliable build-arch would be a really nice thing to have. Option 5 (further discussion): Do nothing. Have this discussion again sometime after Squeeze. Can we please not do this? I see less of a need for a build-indep target. Should we touch that?
Attachment:
signature.asc
Description: Digital signature