Suggested packaging guideline: avoid running autoreconf

[Kevin Kofler]

Braden McDaniel <braden <at> endoframe.com> writes:
> Many one-liner Makefile.am patches are also one-liner Makefile.in
> patches when Makefile.in is modified manually.  There's no reason to be
> shy about doing that.

He explicitly explained that in his case the Makefile.in change was NOT a 
one-liner. And I've seen that many times: Just add an additional source file (a 
one-line Makefile.am change) and watch how much Makefile.in changes.

> Because even if you're perfectly capable using the
> autotools, you're still exposing the package to potential breakage when
> it gets rebuilt with a newer version of the tools.

Newsflash: We're "exposing" all packages "to potential breakage" all the time 
when they "get rebuilt with a newer version of the" GCC and Binutils "tools". 
So what are you going to suggest next: packaging upstream's binaries? :-/

So how are the autotools different from GCC and Binutils?

I wonder if we shouldn't even start treating generated autotools files the same 
way as binary JARs (for which the packaging guidelines mandate that they have 
to be removed and rebuilt from source). They're all generated files.

        Kevin Kofler