Bug#981406: define "makefile" as a GNU Make-compatible makefile; support 'gmake' shebang
On Sat, 30 Jan 2021 12:52:13 -0500 John Scott 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 " 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.
Bug#981406: define "makefile" as a GNU Make-compatible makefile; support 'gmake' shebang
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. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (2, 'unstable'), (1, 'testing-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled debian-policy depends on no packages. Versions of packages debian-policy recommends: ii libjs-sphinxdoc 3.4.3-1 Versions of packages debian-policy suggests: ii doc-base 0.11 -- no debconf information signature.asc Description: This is a digitally signed message part.
