Bug#640874: leave: debian/rules is not a Makefile
On Thu, Sep 08, 2011 at 10:43:44AM +0100, Colin Watson wrote:
> Would you mind explaining here why you feel it is important to retain the
> flexibility of multiple implementation languages for debian/rules?
Now, I wouldn't actually put it that way - because that would imply that we
could suddenly have a plethora of implementation languages for debian/rules,
which might actually become detrimental and that as such cannot and
shouldn't be an important goal.
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.
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.
> 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?
The whole idea that we're changing something in the build-arch handling is a
nice supporting argument for my idea that we don't have a reason to hardcode
make - the fact that we control the API means that we are able to make this
decision, rather than having to adjust to whatever some semi-random program
does.
--
2. That which causes joy or happiness.
Reply to: