Allow rpmbuild user to prevent application of hunks into wrong contexts

[Jeff Johnson]

tracker

[Jan (jan-redhat-bugs)]

Description of problem:

When rpmbuild applies patches, it calls patch with the -s option even if in the .spec file the -s is not specified. This hides warnings from build log, which could lead to things like .orig files being packaged in the rpm. This actually happened with the perl-Frontier-RPC-0.07-7.el5 package.

Version-Release number of selected component (if applicable):

# rpm -qf /usr/bin/rpmbuild
rpm-build-4.4.2-48.el5

How reproducible:

Deterministic.

Steps to Reproduce:
1. run rpmbuild -bp on package which has patches that have non-zero offsets. For example for perl-Frontier-RPC-0.07-7.el5:
# rpmbuild -bp Frontier-RPC.spec

Actual results:

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.46867
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd /usr/src/redhat/BUILD
+ rm -rf Frontier-RPC-0.07b4p1
+ /bin/gzip -dc /usr/src/redhat/SOURCES/Frontier-RPC-0.07b4p1.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd Frontier-RPC-0.07b4p1
++ /usr/bin/id -u
+ '[' 0 = 0 ']'
+ /bin/chown -Rhf root .
++ /usr/bin/id -u
+ '[' 0 = 0 ']'
+ /bin/chgrp -Rhf root .
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ echo 'Patch #0 (perl-frontier-raw-call.patch):'
Patch #0 (perl-frontier-raw-call.patch):
+ patch -p1 -s
+ echo 'Patch #1 (perl-frontier-raw-serve.patch):'
Patch #1 (perl-frontier-raw-serve.patch):
+ patch -p1 -s
+ echo 'Patch #2 (perl-frontier-undef-scalar.patch):'
Patch #2 (perl-frontier-undef-scalar.patch):
+ patch -p1 -s
+ echo 'Patch #3 (security-xml-external-entity.patch):'
Patch #3 (security-xml-external-entity.patch):
+ patch -p1 -s
+ echo 'Patch #4 (apache2.patch):'
Patch #4 (apache2.patch):
+ patch -p1 -s
+ exit 0

Observe the -s in the patch command line. Check the .spec file that there is not such -s there. Also see ../BUILD/Frontier-RPC-0.07b4p1/lib/Frontier/*.orig -- it has .orig files which should not be there:

-rw-r--r-- 1 root root 7210 Apr 30 2007 ../BUILD/Frontier-RPC-0.07b4p1/lib/Frontier/Client.pm.orig
-rw-r--r-- 1 root root 18877 Nov 11 12:08 ../BUILD/Frontier-RPC-0.07b4p1/lib/Frontier/RPC2.pm.orig

Expected results:

rpmbuild should not add options that lower the verbosity of the output or that hide potential problems.

Additional info:

[Jan (jan-redhat-bugs)]

Also cloned for Fedora, bug 471006.

[Panu (panu-redhat-bugs)]

To guard against potentially problematic patches, I think the more useful choice would be porting the default patch fuzz setting from rpm 4.6 (which, if enabled, will abort the build on patches requiring fuzz to apply) than by default exposing all the chatter from patch which you have to manually inspect.

Ack for backporting the default_patch_fuzz patches so that those who care can force strict patch cleanliness, but I don't see just removing -s from the defaults as particularly useful thing.

[Jindrich (jindrich-redhat-bugs)]

Support for optional patch fuzz setting is now backported to RHEL5.

[Jan (jan-redhat-bugs)]

The perl-Frontier-RPC package was just an example of a problem caused by that -s option. My feeling is that rpm/rpmbuild should not be adding the -s option at all, or there should be an easy way to override that default setting.

[Jindrich (jindrich-redhat-bugs)]

The problem reporter described is a bug which needs to be addressed in RHEL5. The general solution is to allow a rpmbuild user to prevent application of hunks into wrong contexts. This can be done by decreasing the fuzz factor for the patch(1) utility. Then patch(1) fails so rpmbuild fails as well. This bugfix is currently present in current packages added to erratum (backported from upstream).

The addition of the -s option by rpm by default is not actually a culprit of the wrong behaviour. It is just a consequence of the fact that patch(1) applies hunks with non-zero offsets and makes backups by default. -s option just causes patch(1) not to be verbose about that. Removing the -s option will cause patch(1) to output warnings but doesn't stop rpmbuild. So it is likely that the .orig files are mistakenly packaged. This will never happen if patch fuzz is set to 0.

Adding a custom options to patch(1) calls from rpmbuild is a RFE and it is actually implemented upstream (#471006). It is not a very good idea IMO to have this RFE backported to RHEL5 because we should keep the rpm patch set as minimal as possible so that it is considerably maintainable. But reported should feel free to file a new bug for this purpose so it is reconsidered in the following updates.

Note to QA:
A test for this bug is to make rpmbuild fail in "rpmbuild -bp foo.spec" where foo.spec contains patch that is not cleanly applicable. You can use rpm package itself for this purpose, as described in comment #6.

[errata-xmlrpc (errata-xmlrpc-redhat-bugs)]

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1371.html