The patch in summary is touching both Makefile.in and Makefile.am, probably to avoid autotools rebuild. This treatment is usually reserved for a few selected system packages that cannot have their autotool scripts rebuilt. This _could_ cause maintainermode-driven rebuild (see http://blog.flameeyes.eu/articles/2008/06/13/maintaner-mode ), which is something we should be avoiding as much as possible. Please just patch Makefile.am and/or configure.in/.ac and rebuild autotools, unless you have very good reasons not to.
I was just about to congratulate you on your QA issue detection abilities, but then I looked at the patch... It seems to be patching Makefile.in only. Is this ok? Or should I still convert this old package to patch Makefile.am instead and then run autotools?
Ah I think this slipped through. There are a few packages like this but I wanted to keep them separate for now, I misfiled this. To sum up, packages only patching Makefile.in when Makefile.am is present are opening for different kind of problems, of which the major ones are: - if maintainer mode is triggered, the patch is silently overridden; - if another dev adds a patch that requires autotools rebuild, he/she might assume that if no autotools were called, all the patch touched sources rather than autotools (yes I know this would be a mistake of that dev, but let's be practical); - if upstream changes the version of autotools, the patch will not apply at all, forcing you to add a different one on bump if it's not fixed yet. There are a few use cases where this is going to bite you, but in general, it's not really a good idea at all. Patching both is somewhat opinable, there are cases where the hassle of rebuilding autotools is way too much, patching just the results can create problems.
Since it didn't even apply anymore (bug #308485), I've dropped the patch altogether.