Hi all,
when trying to fix some packages that have recently become unreproducible after adding build path variations, I have noticed that a common case is that some of these variations make it into Makefiles that have been generated by automake from upstream’s Makefile.in. Some of these Makefiles are included in the packages in question, for instance to automate tests that most likely were intended by upstream to be run at build time.
However, since with the introduction of the new autopkgtests upstream’s test cases are often also installed in /usr/share/doc/…/examples, we see some cases of Makefiles containing build-specific directories ending up in binary packages, since the values for C(XX|PP)FLAGS etc. are propagated from the build environment into these files. An example is [1] where the value of CFLAGS is modified.
I have found some more instances, and I have added some workarounds removing these problematic fields from the Makefile [2] to let them use the default if required — however, I am wondering whether these Makefiles should be installed at all. Cleaning them up would add quite a bit of overhead to the d/rules in each case and I am quite doubtful users would ever touch these Makefiles (if they even work at all).
Any opinions or ideas?
Cheers
Sascha
[1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/hmmer2.html
HMMER3 (package hmmer) is also affected.
[2] https://anonscm.debian.org/cgit/debian-med/toppred.git/commit/?id=8e5b443c66d60de5487c6e526a57828ec5e6a19e
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail