#3 %goprep should apply patches automatically
Opened 2 years ago by nim. Modified 2 years ago

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


Metadata Update from @nim:
- Issue assigned to nim

2 years ago

Metadata Update from @nim:
- Issue tagged with: RFE

2 years ago

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?

How do we handle the case of when patches should be applied manually/conditionally?

That would actually be trivial to handle cleanly

%if <something>
# apply patches 6 87 456 in that order after unpacking source 3
%global source_patches3 6 87 456 
%else
 # only apply patch 666
%global source_patches3 666
%endif

Your patterns would not work because %goprep -a can process several archives sequentially (similar to %forgesetup -a). Anything not based on a declarative syntax quickly drowns in a maze of brittle switches. But, just do not define %source_patches<x> or set it to %{nil}, and you get back to the current situation where patching is separate.

On the other hand intermediary GOPATH creation in %goprep is heavily dependent on the knowledge of what was unpacked where. That’s why splitting it from the unpacking is a terrible idea.

%goprep -e will let you unpack separately, and I’m pretty sure no one will actually use it, because it will only work if you unpack manually exactly as %goprep needs. So it’s less hassle for the packager to do the unpacking in %goprep than figure what %goprep needs. %goprep -e is only there to let people figure by themselves it’s a terrible idea instead of accusing me of being too rigid.

Of course pretty much everything %setup-related in the forge and go macros is just work-arrounding rpm deficiencies that rpm upstream does not see the point in fixing. There is a huge amount of code that could be deprecated if rpm upstream gave up on the original %setup design and provided a %setupng without all the historical documented %setup deficiencies.

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.

I don't think it's needed really, it would complexify %goprep. We can use %autopatch after %goprep to the same effect.

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.

Login to comment on this ticket.

Metadata