From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: Generated patches change over time Date: Sun, 02 Dec 2018 01:24:04 +0100 Message-ID: <87a7lord23.fsf@gnu.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> <87in0hw0ag.fsf@netris.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]:53916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTFYO-0008D2-1a for guix-devel@gnu.org; Sat, 01 Dec 2018 19:24:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTFYM-0001G5-AI for guix-devel@gnu.org; Sat, 01 Dec 2018 19:24:07 -0500 In-Reply-To: <87in0hw0ag.fsf@netris.org> (Mark H. Weaver's message of "Wed, 28 Nov 2018 12:59:08 -0500") 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: Mark H Weaver Cc: guix-devel@gnu.org Hello Mark, Mark H Weaver skribis: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: [...] >> 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. Overall though such patches may typically change several times a year. > I wonder if it would be worth adding a special 'origin' type that > removes the version number from the end of git patches. As I replied to Maxim, this is not really possible. >> 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. Yeah I agree with this. Another concern is unbounded growth of the Git repo. OTOH a patch that changes over time becomes non auditable: you=E2=80=99ll n= otice it has changed, and maybe that=E2=80=99s because of a benign change like th= ose discussed above, but maybe it=E2=80=99s something else; if you can=E2=80=99= t retrieve or reproduce the original patch, you can=E2=80=99t tell what the difference is. So I don=E2=80=99t have a good solution, but I think we should avoid upstre= am patches when we know they are generated in a non-reproducible fashion. Thanks, Ludo=E2=80=99.