First of all Sorry for not quoting. It is just for telling an opinion from someone that know the autofu well, almost. For me this idea of patching generated autofu is wrong. if i have to patching the GNU build system there is a reason of course. Which reason is right for a packager ? Imho in many case it is because the build system is incomplete or wrong ( use only autocof for example, but not automake or don't want to use libtool). In any case can be difficult to change some setting without changing the build system. But now is the problem : the new autofu version know now, and not before, that some costruct is problematic or perhaps no, but they give some cryptic error message. In short the right solutinn in a floss env is to patch configure.ac, makefile.am doing thereafter an autoreconf -vfi and reporting the problem upstream. Nothing of different to patch the code is not fhs or if new compiler flag catch an unseen possible error. Ideally an good floss ecosystem should work, and mostly does, in this way, i think. Why this Could be different for the GNU build system ? Thanks for attending. Best regards. ----Messaggio originale---- Da: drago01 Inviato: 03/07/2011, 19:38 A: Development discussions related to Fedora Oggetto: Re: Calling autoconf in a spec.
On Sun, Jul 3, 2011 at 7:31 PM, Tom Lane <t...@redhat.com> wrote: > Sam Varshavchik <mr...@courier-mta.com> writes: >> To add to that: I never recall a single instance where I couldn't fix any >> breakage in someone else's canned configure/makefile scripts without having >> to rerun autoconf and automake. > >> If there was a problem in the configure script, rather than patching >> configure.ac or configure.in, I simply patched the configure script itself. > > Yeah, and the question is why that's a good idea at all, let alone so > superior as to be policy. To me it sounds exactly like arguing that you > should fix a code bug by patching the emitted assembler code, instead of > touching the C code. Or fixing a grammar problem by patching bison's > output file instead of the input .y file. It just seems uselessly stone > age. And it certainly does not yield a patch that you are going to be > able to submit to upstream. Exactly patching generated code is just wrong period. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
