Bug 471005
| Summary: | Allow rpmbuild user to prevent application of hunks into wrong contexts | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Jan Pazdziora <jpazdziora> |
| Component: | rpm | Assignee: | Jindrich Novy <jnovy> |
| Status: | CLOSED ERRATA | QA Contact: | Petr Sklenar <psklenar> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 5.2 | CC: | bperkins, jhutar, jnovy, jpokorny, pknirsch |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-09-02 11:40:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jan Pazdziora
2008-11-11 11:07:41 UTC
Also cloned for Fedora, bug 471006. 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. Support for optional patch fuzz setting is now backported to RHEL5. 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. 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. 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 |