In article <20040709184232.52453af0.jmmv@menta.net> Julio wrote:
: > The other point (the naming scheme) is important, too. I noticed that 
: > with encoding the file name as the patch name the order in which the 
: > patches are applied only depends on the file name, not on the package 
: > maintainer's opinion. There might be problems with dependent files, such 
: > as ./configure and ./configure.ac, as well as lex and yacc files.
: > 
: > These alternatives came to my mind:
: > 
: > - only patching the relevant file (./configure) and letting
: >    ./configure.ac untouched
: > 
: >    This should cause no problems unless the package rebuilds ./configure
: >    during the build.

: If configure.ac is patched, it's probably because you'll re-run autoconf
: later.  If not (in the very few exceptions), a simple 'touch' after patch
: should be enough.

  Patching configure.ac in addition to configure, even if it is not
used during build, is beneficial for two reasons: feeding the patches
back to the original authors and documenting what actually changes
(which is muh easier to see in the configure.ac case).

  But pkgsrc overrides autoconf et al during build with dummy scripts.
Is it really still important to patch configure.ac before configure?

						yours,
						dillo