As I see it, we have the following options with respect to autoconf related files and use of ./configure script 1. Use autoconf and ./configure script generated by it as optional way to configure installation process. Have configure.ac and config.mak.in in main directory of git.git repository. Do not use ./configure script in git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the contrib/. Leave changes to *.spec file to distributions, documenting it somewhere. 2. Use autoconf and ./configure script generated by it as optional way to configure installation process _and_ in git.spec.in, i.e. in the RPM building. Ship generated 'configure' script with distribution (source) tarball or make patch creating 'configure' script and use it instead in git.spec.in (avoids shipping 'configure' in source tarball). This has the consequence that autoconf would be build dependence for creating RPM at least. Perhaps we can have automatically build configure script in separate branch, similarly to 'man' and 'html branches of git.git. 3. Write our own ./configure script, put it under version control, and put autoconf related files in contrib/ as an alternative. Advantages: we can customize it to git needs and git build process conventions. Disadvantages: duplication of work put into autoconf to make generated ./configure script portable (which is also the case why atoconf generated shel script 'configure' is not very readable, and probably should be not under version control; html and man documentation aren't either). Use %configure in git.spec.in file. Plan for the future? I am partially to [*1*], if just because I wouldn't need to take care autoconf in git. [*2*] has disadvantage in that generated ./configure needs to be put in main directory to work, either by hand (which complicates using this way of building and installing git) or by script (which violates unsaid rule that contrib/ doesn't interfere in top directory). [*3*] would be probably the best, but it is additional work, duplication of autoconf efforts, and need someone (not me) well versed in git compiling woes _and_ shell script portability. -- Jakub Narębski ShadeHawk on #git - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html