Bug 773503
Summary: | rpmbuild silents patch which may cause confusion | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Jan Pokorný [poki] <jpokorny> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED ERRATA | QA Contact: | Patrik Kis <pkis> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 6.4 | CC: | ffesti, jpazdziora, ksrot, pkis |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | 678000 | Environment: | |
Last Closed: | 2013-02-21 10:51:13 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 Pokorný [poki]
2012-01-12 01:56:05 UTC
s/3rd package/3rd party package/ Moving to rhel-6.4 for further consideration, this isn't exactly a critical issue. Also you can already override %_default_patch_flags to remove the -s from %patch invocations. FWIW, default changed to non-silent in upstream now. Thanks. Any chance to get RPM patching process to be completely sane (perfect match or fail/break the build) as expressed in [comment 0]? Please note, IIRC, that is a default behavior of git-patch, and git is known to do the right things :) Rpm already defaults to zero fuzz tolerance, but AFAIK patch doesn't have a "strict mode" beyond that. I'd be happy to support it in rpm if it did... Yep, just noticed the brewtap tool and its "warning" assesment when nonzero fuzz is used to build a RHEL6+ package ([bug 692142]). This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release. Related issue, patch tool used by RPM does not recognize GIT binary patches, but it does not complain about this neither(!) [1,2] Simply, there should be much higher guarantees that nothing goes wrong with the patches because this patch-based model is so vital. I also filed a RFE for BrewTap (perhaps indirectly Rpmdiff): [bug 850918]. [1] http://pkgs.devel.redhat.com/cgit/rpms/conga/tree/bz786372bz607179.patch?h=rhel-5.9&id=6feeb5279021a436ba0ec6a7be3a4a48484aeddd#n1391 [2] http://download.devel.redhat.com/brewroot/packages/conga/0.12.2/60.el5/data/logs/x86_64/build.log (scroll down a bit to "Patch #68 (bz786372bz607179.patch):") Btw. it seems that we are quite behind the upstream regarding "patch." See 2 years old upstream commit [3]; I tried the attached test case and at both RHEL 5.8 and F17, I am getting: $ patch -p1 < f.diff patch: **** Only garbage was found in the patch input. If at least the referenced commit was applied at our side, I would be warned in the mentioned case (one of possible desired outcomes) :-/ I am a bit lost here. Could you please summarize the changes planned for fixing this bug? Also please update severity/priority. Thank you. The change to rpm in its entirety is this one-line change to the default macros :) http://rpm.org/gitweb?p=rpm.git;a=commitdiff;h=933a3e32dd94c5d54d10c24c55394488824de1f0 To avoid described issues, it seems most viable to me the solution described at [3] I was indirectly pointed to. Unfortunately and as a bit of a surprise, RHEL 5 does not offer git directly (requested with [bug 851184]). In the longer term, the solution to [4] looks promising, thanks Panu. [3] http://rwmj.wordpress.com/2011/08/09/nice-rpm-git-patch-management-trick/ [4] http://www.rpm.org/ticket/54 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0461.html |