[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposed release goal: fix debian/rules build-arch

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

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

Reply to: