Red Hat Bugzilla – Bug 450352
squid-3.0.STABLE1-build.patch only patches generated files
Last modified: 2014-11-09 17:31:02 EST
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):
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. ;)