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 <tgl(a)redhat.com> wrote:
Sam Varshavchik <mrsam(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel