[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#981406: define "makefile" as a GNU Make-compatible makefile; support 'gmake' shebang



On Sat, 30 Jan 2021 12:52:13 -0500 John Scott <jscott@posteo.net> wrote:
> Package: debian-policy
> Version: 4.5.1.0
> Severity: minor
> 
> At the moment, debian/rules is required to be a Makefile, but it's not
> exactly defined. In the absence of an explicit statement it seems most
> reasonable that it would be inherited from POSIX, but use of GNU extensions
> are liberal even in the Makefile excerpts provided by dpkg, for example.
> As make is notorious for its vendor-specific variants, this stands to be
> clarified.
> 
> Specify, perhaps in the Definitions section, that a Makefile is a file to
> be usable with GNU Make. This makes explicit that GNU Make is the
> standard, and implies that provided Makefiles may use such extensions.
> 
> On the topic, the GNU Make package now provides the 'gmake' binary, and
> the requirement that debian/rules starts with '#!/usr/bin/make' seems overly
> strict. Analogously to the requirements for shell scripts, I would like to
> make my GNU makefiles start with '#!/usr/bin/gmake' for explicitness:
> > If a shell script requires non-POSIX.1-2017 features from the shell
> > interpreter other than those listed above, the appropriate shell must be
> > specified in the first line of the script (e.g., #!/bin/bash) and the
> > package must depend on the package providing the shell (unless the shell
> > package is marked “Essential”, as in the case of bash).
> GNU Make extensions are the status quo, so I'd merely like it to be
> permissible to use the 'gmake' shebang line, or perhaps one that's
> functionally equivalent.
> 
> [...]
Hi,

Personally, I am the stage that if we are touching this piece of the
policy, I would like to remove the strict requirement for debian/rules
being make.

My proposal is therefore that the actual requirement would be that
"./debian/rules <target>" must satisfy the policy requirements (as
before) and then have a non-normative paragraph saying that this in
practise has to be a GNU makefile using the shebang of make (or gmake)
due to the current tooling assuming (GNU) make in various places.

A bit of context: Before 2012 it was possible to use a "non-make"
debian/rules.  This "feature" was removed with our transition to mandate
build-{arch,indep} targets as dpkg was expected to use "make -qn" to
detect the presence of these optional targets (see #629385 - there
should also be a ctte bug overruling a maintainer with an sh d/rules
somewhere, but I cannot find it atm.).  However, we are now back to dpkg
supporting a non-make debian/rules again (via a side-effect in the R³
implementation)[1].

My personal reason for this solution is that I am working on removing
the "make layer" between dpkg-buildpackage and dh in the hope that it
will enable us to make some concrete improvements.  In practise the make
layer will probably still be around for a decade or more (but it would
cross off one thing on my todo list now rather than later).


Thanks,
~Niels

[1] But as said, in practise you still need make here except for the
ultimate base cases. Like dh assumes make.


Reply to: