Currently `dh_install` for makefile-based project sets the `DESTDIR`
variable only.

(See
<https://salsa.debian.org/debian/debhelper/-/blob/3d91b51f/lib/Debian/Debhelper/Buildsystem/makefile.pm#L192-194>.)

According to the GNU guidelines there are other standard variables that
an installer should set, the most important of which is `prefix=`.

 From
<https://www.gnu.org/prep/standards/html_node/Directory-Variables.html>:

 > "prefix"
 >
 >    A prefix used in constructing the default values of the variables
 >  listed below. The default value of prefix should be `/usr/local` […]

and

 > Installers are expected to override these values when calling
 > make (e.g., make prefix=/usr install)

A code search shows that setting `prefix=` and `sysconfdir=` is quite
common in `d/rules` files:

https://codesearch.debian.net/search?q=%5B%5E-%5Dprefix%3D%2Fusr+path%3Adebian%2Frules&literal=0&perpkg=1

Given that debhelper sets `DESTDIR`, couldn't it also set `prefix` and
all other common makefile variables, just like it does for
autoconf-based projects (see
<https://salsa.debian.org/debian/debhelper/-/blob/main/lib/Debian/Debhelper/Buildsystem/autoconf.pm#L36-41>)?

Regards,

Gioele Barabucci:

I find it curious that a number of these matches do not seem to apply to
`make install` or `dh_auto_install`. Instead they are sometimes also
used for `make` (e.g., the build phase rather than the install phase).

Just to set the expectations of how much benefit this change can result
in as far as "reducing the number of cases with explicit prefix=/usr".

My "gut" feeling from scrolling over ~5 pages leaves me with a 40%/50%
rate of cases where the package might benefit from it to the point where
prefix=/usr would disappear (if/when people use dh_auto_install rather
than "make install" - not all the "make install" lines I saw could
easily be converted).

  1) How many packages will this change break?

  2) How easy will it be for people to realize this change is what breaks
     stuff and how to resolve it. Like can we come with a "one-size fits
     all" answer for how to undo this change if it breaks a specific
     package?

I think those two questions should be the counter-weight compared to the
gain when evaluating whether we should apply this change and I would
like to see the numbers/proposals for these to before saying whether we
should move forward with this change.

Note: I am assuming this would require a compat bump. So for the
answers, it is really about how painful will that compat bump be for the
users of debhelper.

Best regards,
Niels