Bug 471005 - Allow rpmbuild user to prevent application of hunks into wrong contexts
Allow rpmbuild user to prevent application of hunks into wrong contexts
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jindrich Novy
Petr Sklenar
Depends On:
  Show dependency treegraph
Reported: 2008-11-11 06:07 EST by Jan Pazdziora
Modified: 2014-01-27 05:42 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:40:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1371 normal SHIPPED_LIVE rpm bug fix update 2009-09-01 07:05:57 EDT

  None (edit)
Description Jan Pazdziora 2008-11-11 06:07:41 EST
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

How reproducible:


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 -
+ '[' 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:
Comment 1 Jan Pazdziora 2008-11-11 06:12:17 EST
Also cloned for Fedora, bug 471006.
Comment 2 Panu Matilainen 2009-01-16 09:32:26 EST
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.
Comment 3 Jindrich Novy 2009-05-06 10:49:58 EDT
Support for optional patch fuzz setting is now backported to RHEL5.
Comment 10 Jan Pazdziora 2009-07-08 15:25:48 EDT
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.
Comment 12 Jindrich Novy 2009-07-29 05:12:44 EDT
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.
Comment 15 errata-xmlrpc 2009-09-02 07:40:28 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.