Bug#640874: leave: debian/rules is not a Makefile

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Josip Rodin writes ("Bug#640874: leave: debian/rules is not a Makefile"):
> Since my reasoning here didn't seem to leave a particular positive dent with
> those tech-ctte members who have responded so far, I would just like to
> solicit Ian Jackson's input, given his role in defining and implementing the
> debian/rules calling convention originally. In other worse, if I can't
> convince the original author of a non-make-dependent API that the API isn't
> make-dependent, there is no recourse but to yield :)

It's very tempting to close down this discussion by agreeing that we
always intended debian/rules to only be allowed to be a makefile.  But
I'm afraid that I'm going to agree with Josip on this point: as far as
I remember, the designers (of which I was one) did not originally
intend this restriction.  If I had intended it I would have written it
into the original policy manual.

That doesn't mean that in the current circumstances it isn't
reasonable to make that requirement, of course.  But I'm not convinced
by the arguments made so far in favour of this requirement.

It's true that having a standardised implementation language can
make it easier for people unfamiliar with the package to work with it,
and this is indeed something that we should care about.

But I agree with Josip's point about the spirit vs. the letter: if we
write into policy that debian/rules must be a makefile, Josip can
comply with the policy by what amounts IMO to trickery.  And it's not
trickery that's simple to forbid, given that that trickery is exactly
what dh(1) uses.

Or to put it another way, we have two plausible options:

 1. Weaken the rule that debian/rules must be a makefile, from a
    requirement to a recommendation.

 2. Require that it be a makefile but permit
	#!/usr/bin/make -f
	%:
		debian/myscript $@
    and also:
        %:
		dh $@

And one implausible one:

 3. Require that it be a makefile and FORBID
	%:
		debian/myscript $@
    but PERMIT
        %:
		dh $@

Of these I prefer option 1.  It is at least coherent.  An imprecation
in policy /recommending/ the use of make or dh(1) would be sensible.

Option 2 is pointless IMO.  It mandates that Josip do something
pointless, and leaves the same door open for other pointless things.

Option 3 is very difficult: how do we distinguish these two cases ?
Are we going to make a special exception for dh(1), thus forbidding
future package helper tools that aren't explicitly blessed by policy ?
I don't think that's the right way to go.

Ian.