[go-rpm-macros] Issue #3: %goprep should apply patches automatically

[Nicolas Mailhot]

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

[Nicolas Mailhot]

The issue: `%goprep should apply patches automatically` of project: `go-rpm-macros` has
been assigned to `nim` by nim.

https://pagure.io/go-rpm-macros/issue/3

[Neal Gompa]

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

[Nicolas Mailhot]

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

[Nicolas Mailhot]

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

[Robert-André Mauchin]

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

[Jakub Čajka]

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

[Mikel Olasagasti Uranga]

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...

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