On Sun, 2008-10-12 at 01:19 +0000, Kevin Kofler wrote: > 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. I wasn't contesting the reality of that scenario. I was merely pointing out that Makefile.am changes aren't always so explosive; and how where they aren't, noise generated from generating Makefile.in with a different version of automake than upstream used can be avoided. But in any case, who really cares if the patch is big as long as the changes are necessary and appropriate? > > 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? :-/ We can do without the strawman. > So how are the autotools different from GCC and Binutils? Source packages produced by an autotools build are designed to be buildable in the absence of the autotools themselves. They are not designed to be buildable without a compiler and POSIX environment. Did that really have to be said? > 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. Probably the reason there is no guideline treating all generated files the same way is that doing so is a really dumb idea. -- Braden McDaniel e-mail: <braden@xxxxxxxxxxxxx> <http://endoframe.com> Jabber: <braden@xxxxxxxxxx> -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
