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.
a) The package already calls eautoreconf due to another patch that is applied against it b) No maintainermode driven rebuild is triggered c) I prefer to patch Makefile.in as well if easily possible to save thousands of users from having to wait on an insanely slow eautoreconf to complete d) I don't see how or why patching Makefile.in can trigger anything that couldn't be triggered without patching it - say in case of a clock skew - should we start to call eautoreconf for everything even if we don't patch anything or what? I consider this bug INVALID until proven technically that this actually causes trouble. For example debian's experience seems to say "there are no problems", as they patch configure and Makefile.in's ALWAYS when touching configure.ac or Makefile.am's.