From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Generated patches change over time Date: Wed, 28 Nov 2018 12:59:08 -0500 Message-ID: <87in0hw0ag.fsf@netris.org> References: <20181124183051.23027.37347@vcs0.savannah.gnu.org> <20181124183052.9A76B209A2@vcs0.savannah.gnu.org> <87h8g5unug.fsf@gnu.org> <87pnuskfmg.fsf@netris.org> <87h8g15uqb.fsf_-_@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50390) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gS47w-0006Rs-BU for guix-devel@gnu.org; Wed, 28 Nov 2018 12:59:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gS47t-0008JB-3Z for guix-devel@gnu.org; Wed, 28 Nov 2018 12:59:56 -0500 In-Reply-To: <87h8g15uqb.fsf_-_@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\?\= \=\?utf-8\?Q\?\=22's\?\= message of "Wed, 28 Nov 2018 12:04:12 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: guix-devel@gnu.org Hi Ludovic, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> --- t.patch 2018-11-25 16:26:38.946968736 -0500 >> +++ b182c6b9e1d09e601bac0b703cc5f8b159ebbc3a.patch 2018-11-25 14:53:32.0= 19264658 -0500 >> @@ -19,7 +19,7 @@ >> 1 file changed, 1 insertion(+), 1 deletion(-) >>=20=20 >> 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 >> +--=20 >> +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=E2=80=99s 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