Description of problem: squid-3.0.STABLE1-build.patch only patches autotools-generated files without patching their sources, too. In case of src/Makefile.in it even makes changes to the (un)install-dataDATA targets that obviously aren't the result of Makefile.am changes. As a result, when making custom packages that include additional patches that patch autotools source files only/conflict in patching generated files due to different autotools versions used, rerunning autotools to generate files including all the changes (to in turn generate a patch from) fails, dropping all the changes from squid-3.0.STABLE1-build.patch. The attached patch fixes these issues, but only patches the Makefile.am files (as my trees have additional patches before the Fedora ones and I have different autotools anyway (backporting to FC8)). To get a replacement for squid-3.0.STABLE1-build.patch, you'd have to run './bootstrap.sh && rm -rf autom4te.cache lib/libTrie/autom4te.cache' before diffing. Version-Release number of selected component (if applicable): 7:3.0.STABLE2-3
Created attachment 308572 [details] patch autotools source files to achieve same results as squid-3.0.STABLE1-build.patch
Is there any reason to move conf file from the /etc path? The squid-3.0.STABLE1-build.patch patches really autotools-generated file. The reason of this is that Makefile.in is contained in the tarball and build process uses tarball's Makefile.in. Therefore your Makefile.am changes was not applied - no due to squid-3.0.STABLE1-build.patch.
The Makefile.in is the right file to patch in accordance to guidelines. I optimized and repaired "build" patch and I extended the patch also to patch Makefile.am.
Yes, the point was never that the build as is was wrong, just that it made adding 3rd-party patches in custom packages derived from the Fedora one considerably more tedious. So, thank you for making my life a bit easier. ;)