On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote:
> I've yet to see a technical argument for allowing debian/rules to be a
> non-makefile.
I've yet to see a technical argument for disallowing debian/rules from being
a non-makefile.
See, those two statements make the same amount of sense. Anyone can throw in
gobs of make features that are handy, and also gobs of other interpreters'
features that are handy as well. That doesn't make any one of them technical
arguments for either.
> If you really want to write the script in a different format, it's trivial
> to meet the letter of Policy:
And it's also trivial to change the letter of Policy, too.
Contrary to what some may have said, replacing the crude "must" rule will
not cause anything to happen other than fixing a spurious requirement that
exists in the documentation only.
No, new maintainers won't suddenly start shipping precompiled a.out
debian/rules files. They probably won't start using vertical Perl either.
In fact the most likely result is that not one thing will change, except
that a tiny fraction of packages will no longer be in "violation of policy".
> That I've never seen such done (in my admittedly limited and random
> selection of packages to build by hand at various times) suggests that
> there's not much practical demand. Whenever it's come up, it seems to be
> someone trying to prove a point, rather than a technical need.
I have had packages the rules file of which is not a makefile for years now.
You didn't notice them, did you? That's probably because they (*gasp*!) work.
And none of those purported NMUers ever complained about them either.
Arguably that's because of other favourable circumstances, but nevertheless.
The interface to the rules file is defined well enough, there's absolutely
nothing wrong with having other things than /usr/bin/make abide by the same
rules.
--
2. That which causes joy or happiness.
