nim reported a new issue against the project: `go-rpm-macros` that you are following: `` `%goprep` should apply patches automatically, so there is no convenience gap with `%autosetup`.
This is generic work that should be done *redhat-rpm-config* side in forge macros and then reused in`%goprep`. Basically:
1. define a `patch_flags<suffix>` rpm variable holding the parameters that should be passed to `%patch<suffix>` 2. define a `default_flags<suffix>` fallback 3. define a `source_patches<suffix>` holding an ordered space separated list of patch suffixes associated with a particular forge/go source.
And then write the usual lua loops to apply it all at the right moment in the spec. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
The issue: `%goprep should apply patches automatically` of project: `go-rpm-macros` has been assigned to `nim` by nim.
ngompa added a new comment to an issue you are following: `` How do we handle the case of when patches should be applied manually/conditionally?
Is it demonstratively worse to have either
``` %gosetup %goautopatch %goprep ```
or
``` %goautosetup %goprep ```
instead? ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
nim added a new comment to an issue you are following: ``
How do we handle the case of when patches should be applied manually/conditionally?
That would actually be trivial to handle cleanly ```specfile %if <something> %global source_patches3 6 87 456 # apply patches 6 87 456 after unpacking source 3 in that order %else %global source_patches3 666 # only apply patch 666 ```
``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
nim added a new comment to an issue you are following: `` And of course the nice thing of using documented rpm variables instead of macro-specific switches, is that any other macro can read the same variables and implement some other smarter form of processing, without requiring argument surgery. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
eclipseo added a new comment to an issue you are following: `` I don't think it's needed really, it would complexify %goprep. We can use %autopatch after %goprep to the same effect. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
jcajka added a new comment to an issue you are following: `` I second @eclipseo. Autopatch would add complexities in complex situations(would made using goprep impossible). Notably I have on my mind architecture specific patches, which are not possible with autopatch. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
mikelo2 added a new comment to an issue you are following: `` `go2rpm` includes `autopatch -p1` in the template since release 1.9.0
https://pagure.io/GoSIG/go2rpm/c/b7ba195ebf85c2b7025a7d27e0623eb87f0be89b?br...
It differs from the initial request of this issue, but should be enough IMO. ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
The status of the issue: `%goprep should apply patches automatically` of project: `go-rpm-macros` has been updated to: Closed by gotmax23.
gotmax23 added a new comment to an issue you are following: `` The recommended approach to automatically apply patches is now
``` %goprep -A %autopatch -p1 ``` ``
To reply, visit the link below or just reply to this email https://pagure.io/go-rpm-macros/issue/3
golang@lists.fedoraproject.org
-
Jakub Čajka -
Maxwell G
-
Mikel Olasagasti Uranga
-
Neal Gompa
-
Nicolas Mailhot
-
Robert-André Mauchin