Bug#640874: leave: debian/rules is not a Makefile
On Thu, Sep 08, 2011 at 02:38:15PM +0200, Josip Rodin wrote:
> But, to return to the former idea of arguing for flexibility for just one
> moment - that's moot because of another reason - we *already* allow a
> near-infinite amount of abuse through flexibility, because you can make a
> makefile fork another program and do whatever afterwards. It would abide by
> the letter of the rules, and people have suggested to me that I do that, but
> I don't think that would be in line with the spirit of the rules, which
> provide a nice, clean description of what gets done for which specified
> action or variable, so the code should roughly match such a description
> without a lot of necessary overhead.
>
> Heck, even the typical dh(1) debian/rules file (so typical I pasted it
> straight from its manual page):
>
> #!/usr/bin/make -f
> %:
> dh $@
>
> does not strike me as better than a shell script such as the one used by
> leave's debian/rules file - in fact it's seems more opaque and needs more
> documentation/knowledge to figure out in what way does this follow
> the rules set out in the policy.
In practice, though, this is the only case I've heard of like this, and
it's balanced by a few points:
* 38% of the source packages in Debian unstable use dh(1). While
popularity isn't always the best measure, at this point, there is
clearly no shortage of developers who understand dh(1), find it
straightforward to inspect and modify, and could be roped in for
assistance if need be.
* debhelper in general, including dh(1), has an excellent track record
at keeping up with policy changes and helping packages to follow
policy, and nowadays it very often does a better job than people
trying to keep up by hand. The first-glance opaqueness of the tiny
rules style seems to have good results in practice.
* While it's true that make is largely delegating responsibility to
another program here, it's a common program used by many packages,
and so serves to consolidate a lot of boring common code which is a
fairly standard software virtue. I'd be hard-pressed to codify
this, but that does seem different in kind from forking a secondary
rules implementation local to a single source package simply for the
purpose of switching language.
> Instead, it is important to retain the age-old idea that the rules file has
> its own calling convention (an API) that isn't linked to one specific
> implementation and is instead properly specified in Debian policy, allowing
> developers some common-sense leeway and the ability to adjust the API if and
> when necessary.
[...]
> On Thu, Sep 08, 2011 at 10:43:44AM +0100, Colin Watson wrote:
> > I can provide a concrete practical reason for requiring make as the
> > implementation language: at least one, probably two, of the options for
> > build-arch handling
> > (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629385#93) require
> > debian/rules to be a Makefile. The leave package might be able to get
> > away with a little bit more if its exit code matched that of make for
> > nonexisting targets, mentioned in policy 4.9; however, it exits 1 rather
> > than 2 in this case. I realise that this may be because you are unable
> > to upload new versions with the shell implementation.
>
> Implementing a return code handler seems perfectly sensible. The idea that
> programs can return a variety of codes to indicate a variety of conditions
> is both ancient and pervasive. Even testing the result of make -qn is
> basically repeating the same thing, so why add an additional dependency?
Conflating "is this option supported" with execution is not without
problems. Here's a simple example of a case where testing by execution
gives the wrong answer; I haven't made it entirely plausible, but 'test'
is a common enough command that I'm sure it's easy to imagine more
realistic versions:
#! /usr/bin/make -f
build-arch:
# we forgot the closing ]
[ foo
Sure, in the specific case of build-arch it happens that this probably
fails harmlessly, but I at least find that non-obvious enough that I
have to think about it. Without wishing to get into the make vs.
Build-Options debate in this bug report, since that's a matter for
#629385, this suggests to me that there is at least room for an
interface that queries capabilities without actually executing code from
the targets in question [1], and that exit codes aren't that interface.
I have some sympathy with the core argument that the interface is
'debian/rules build' etc. rather than 'make -f debian/rules build', but
there just doesn't seem that much to be gained in practice from lifting
the restriction again, and potentially some interesting things to lose.
[1] 'make -qn' isn't *quite* that; it still executes $(shell) commands,
which means that Lintian can't use it. However, the fixed
implementation language is still of benefit to Lintian, since it can
parse debian/rules to test whether required and recommended targets
are present.
Regards,
--
Colin Watson [cjwatson@debian.org]
Reply to: