Re: Generated patches change over time

[Mark H Weaver <mhw@netris.org>]

Hi Ludovic,

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> --- t.patch	2018-11-25 16:26:38.946968736 -0500
>> +++ b182c6b9e1d09e601bac0b703cc5f8b159ebbc3a.patch	2018-11-25 14:53:32.019264658 -0500
>> @@ -19,7 +19,7 @@
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>  
>>  diff --git a/plugins/fmradio/rb-fm-radio-gst-src.c b/plugins/fmradio/rb-fm-radio-gst-src.c
>> -index 09d709c..88abdaf 100644
>> +index 09d709c28..88abdaf35 100644
>>  --- a/plugins/fmradio/rb-fm-radio-gst-src.c
>>  +++ b/plugins/fmradio/rb-fm-radio-gst-src.c
>>  @@ -178,7 +178,7 @@ plugin_init (GstPlugin *plugin)
>> @@ -31,6 +31,6 @@
>>   		   "element to output silence",
>>   		   plugin_init,
>>   		   VERSION,
>> ---
>> -libgit2 0.27.1
>> +-- 
>> +2.18.1
>
> Thanks for checking.
>
> Lesson learned: we should not rely at all on generated patches because
> they are bound to change frequently (version string at the end, length
> of commit hash prefixes, etc.)  It’s probably worse than tarballs
> generated by Git hosting services.

I guess the length of the commit hashes probably won't change very
often, so the version number is the most pressing issue here.  I wonder
if it would be worth adding a special 'origin' type that removes the
version number from the end of git patches.

> So we should probably work towards using local copies of patches, unless
> we find that the generated patches do not include any variable bits.

It might still be best to work towards using local copies of patches,
although in the case of IceCat the set of patches is often quite large.

Another issue to consider is that the use of local copies of patches
involves putting more trust in contributors, in practice, or at least it
seems so to me.  When someone adds a non-obvious patch from upstream as
a local file, it leads me to want to check to make sure it hasn't been
modified from the upstream version, whereas if the package recipe
fetches a patch from a URL that is clearly from the upstream git
repository, it's somewhat more transparent what's going on.

That's not to say that I've reached a conclusion on this issue, but it's
another factor to consider.

     Regards,
       Mark