(I am running current 9999, latest non-live is 3.0.30-r1) I was trying to patch gtk+:3 with https://gitlab.gnome.org/GNOME/gtk/-/commit/5a0ffbbb4568e39bdf26006e1bf18c1c1d0d597a which deals with binary files. The patch invocation complains that "File gtk/icons/16x16/actions/application-exit.png: git binary diffs are not supported." (etc...) Request is to have portage use "git apply" in such cases (when installed, and suggest installation otherwises). Reproducible: Always
PMS specifies the use of patch, so this is a PMS bug, not a portage one.
(In reply to dwfreed from comment #1) > PMS specifies the use of patch, so this is a PMS bug, not a portage one. It's not realistic for us to do that in PMS imo but completely reasonable to consider it for userpatches. Possibly confusing but still.
12.1.1 of PMS says, "gnu-patch patch must be available, and must support all inputs valid for GNU patch, version as listed in table 12.1." So, doesn't GNU patch support binary diffs? https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12700012.3.7 specifies some invocations, but that would seem to disallow `--binary`.
https://savannah.gnu.org/bugs/?57434 PMS for eapply_user() says: "Takes no arguments. Package managers supporting it apply user-provided patches to the source tree in the current working directory. Exact behaviour is implementation defined and beyond the scope of this specification. Package managers not supporting it must implement the command as a no-op. ..." So it would allow for Portage implementation of eapply_user() to use `git apply` instead of GNU patch...
(In reply to John Helmert III from comment #3) > 12.1.1 of PMS says, "gnu-patch patch must be available, and must support all > inputs valid for GNU patch, version as listed in table 12.1." > > So, doesn't GNU patch support binary diffs? > > https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-12700012.3.7 specifies some > invocations, but that would seem to disallow `--binary`. PMS wouldn't forbid it, but GNU patch doesn't support binary patches. It has a --binary option, but the only thing it does is to disable the CRLF/LF line ending heuristic. In other words, GNU patch cannot apply a diff generated by "git diff --binary", so eapply (and eapply_user) cannot do that either. (In reply to dwfreed from comment #1) > PMS specifies the use of patch, so this is a PMS bug, not a portage one. So what should it specify instead? Support any binary diff format that is out there? bsdiff, rdiff, xdelta3, git diff (which are all incompatible with each other)? Also, how would you do "git apply" in an unpacked ${S} which is normally not a git repository?
`git apply` works in directory located outside any git repository.
Instead of adding our own distro specific code, how about adding support to GNU patch, which would help everyone? Looks like upstream wouldn't refuse it ("feel free to send code"): https://lists.gnu.org/archive/html/bug-patch/2009-11/msg00001.html Detection for git binary patches is already there: https://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n696
(In reply to Ulrich Müller from comment #7) > Instead of adding our own distro specific code, how about adding support to > GNU patch, which would help everyone? Looks like upstream wouldn't refuse it > ("feel free to send code"): > https://lists.gnu.org/archive/html/bug-patch/2009-11/msg00001.html > > Detection for git binary patches is already there: > https://git.savannah.gnu.org/cgit/patch.git/tree/src/pch.c#n696 This would not only be very useful for user patches, but also for git-generated patchsets from upstream repositories...
