From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: Generated patches change over time Date: Sun, 02 Dec 2018 15:33:34 -0500 Message-ID: <874lbvoeh2.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> <87r2f1q671.fsf@gnu.org> <87zhto3mnz.fsf@netris.org> <87zhtop60y.fsf@gnu.org> <8736rf3emp.fsf@gmail.com> 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]:34479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gTYRf-0000Rt-4U for guix-devel@gnu.org; Sun, 02 Dec 2018 15:34:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gTYRZ-0005JW-Ih for guix-devel@gnu.org; Sun, 02 Dec 2018 15:34:26 -0500 In-Reply-To: <8736rf3emp.fsf@gmail.com> (Maxim Cournoyer's message of "Sun, 02 Dec 2018 14:36:14 -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: Maxim Cournoyer Cc: guix-devel@gnu.org Maxim Cournoyer writes: > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > > [...] > >> You=E2=80=99re right, along the same lines, it could be a fixed-output >> derivation. >> >> The problem is rather that the workflow would be a bit awkward: =E2=80= =98guix >> download=E2=80=99 would download the raw, unprocessed patch, and thus it= would >> give you the =E2=80=9Cwrong=E2=80=9D hash. >> >> In essence you=E2=80=99d have to put a random hash in your package defin= ition, >> run =E2=80=9Cguix build -S=E2=80=9D, copy the correct hash from the erro= r message, >> manually look at the patch, etc. >> >> It=E2=80=99s possible, but it=E2=80=99s a bit awkward IMO. >> >> Or we would need to add a =E2=80=98--strip-patch-metadata=E2=80=99 optio= n to =E2=80=98guix >> download=E2=80=99 so that it applies the exact same transformation when >> downloading. > > The way I see it, `guix download' should just do the right thing -- the > metadata stripping should be baked in and not user > controllable. Alternatively, it could be controllable, but enabled by > default. This would keep the workflow the same as it is now. I *certainly* don't want "guix download" to try to automatically detect that the downloaded file contains a patch, after some possibly nontrivial amount of plain text which is typically present in patch files, and to canonicalize the patch in that case. However, we could add an optional flag to "guix download", or perhaps add another 'guix' subcommand, to request the use of a specific 'origin' type. In addition to supporting canonicalized patches, this could also improve the workflow for other origin types such as 'git-fetch' and 'hg-fetch'. In general, the specified 'origin' type would determine the number and meaning of the arguments, e.g. for 'git-fetch' an additional commit argument would be needed. Thoughts? Mark