Hi Josip, On Thu, 08 Sep 2011, Josip Rodin wrote: > 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.
The API is not the only thing to take into account. Using anything else than make is unexpected for most other developers (some of them who might have to NMU your package at some point). > 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. Yes, but it's also not worse than having to read the sources of a shell script. And still, this is a Makefile so you can quickly reuse Makefile snippets that others have been writing to add support for supplementary targets (like get-orig-source) or even to influence the environment (like the Makefile snippets that dpkg 1.16.1 is going to provide). So I really don't understand why you insist on keeping debian/rules as a shell script. Moving it one level deeper in the process tree does not strike me as a big performance/readability loss, certainly not one worth spending the time of tech-ctte members on such a case. > 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. If you ignore all transitions constraints, sure. At the same time, Debian decided debian/rules must be a Makefile and you're not adjusting to cope. Why should you better accept another API design compared to an already existing policy requirement? Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
