Having the same Makefile and make-helper.bsh in every package is less than ideal.
- It's a giant code duplication (although packaging-helper-script's function pkg_packaging_files_diff helps to check if they all match).
- Cumbersome to update.
- Requires package version bump just because makefile generic was updated even if that update is not required for that package.
Instead a genmkfile package that ships a file /usr/bin/genmkfile could be installed. Instead of make deb-pkg etc., we could then type genmkfile deb-pkg.
- much less code duplication
- when grepping the code, fewer results are shown
- easier to update generic make files
- in most cases (unrelated generic make file updates), packages would stay the same, would still have an identical hash
- much less packages have to be updated when updating makefile generic
- new package to be created
- packages would be no longer "standalone" (they are not anyhow, a lot other build dependencies required to create Debian packages)
- new build dependency that we would either, and/or:
- require builders to install before building,
or requiring builders to at least adding genmkfile to PATH, or by typing for example /path/to/somewhere/genmkfile deb-pkg instead of make deb-pkg
Why should always all generic makefile be updated?
Otherwise it would be hard to audit ~100 slightly different generic makefiles for non-maliciousness. Since they all match, the following can be used to automate auditing them.
(Or perhaps others are using other custom scripts for such tasks.)
Debian's UpstreamGuide (a pre-condition to get stuff merged into Debian) wants:
- Out-of-Tree Builds
Maybe it's not all that simple.
- Major: Debian build tools expect common make targets such as make install and make clean. By having a /usr/bin/genmkfile most likely changes to debian/rules would be required.
- Minor: having a Makefile around enables make's / bash's competition feature. If we were to expect a genmkfile package by default, we could also ship a bash complementation snippet.
 Not possible, otherwise would be an "optional build dependency", which would be strange. Either we will be using Build-Depends: genmkfile or not. Making it optional is not possible in any clean way.