From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#22423: git-fetch does not update checked out tree when commit hash changes Date: Thu, 21 Jan 2016 17:25:40 +0100 Message-ID: <87vb6mzypn.fsf@gnu.org> References: <20160121065403.GA4278@thebird.nl> <87twm79v05.fsf@gnu.org> <20160121090853.GA4914@thebird.nl> <87vb6n1bw9.fsf@gnu.org> <20160121115002.GA23171@novena-choice-citizen.lan> 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]:38792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMI3k-0001RE-BN for bug-guix@gnu.org; Thu, 21 Jan 2016 11:26:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMI3e-0000to-7e for bug-guix@gnu.org; Thu, 21 Jan 2016 11:26:08 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:40193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMI3e-0000tk-3a for bug-guix@gnu.org; Thu, 21 Jan 2016 11:26:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aMI3d-0000k3-W5 for bug-guix@gnu.org; Thu, 21 Jan 2016 11:26:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <20160121115002.GA23171@novena-choice-citizen.lan> (Jookia's message of "Thu, 21 Jan 2016 22:50:02 +1100") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org To: Jookia <166291@gmail.com> Cc: 22423-done@debbugs.gnu.org Jookia <166291@gmail.com> skribis: > On Thu, Jan 21, 2016 at 11:10:14AM +0100, Ludovic Court=C3=A8s wrote: >> Pjotr Prins skribis: >>=20 >> > On Thu, Jan 21, 2016 at 09:50:18AM +0100, Ludovic Court=C3=A8s wrote: >> >> This is expected: origins are fixed-output derivations, meaning that = it >> >> does not matter how we perform them (using Git, over HTTP, or thanks = to >> >> an avian carrier), as long as the result has the specified sha256. >> >>=20 >> >> Thus, when you change, say, the Git commit ID or origin =E2=80=98meth= od=E2=80=99 without >> >> changing the =E2=80=98sha256=E2=80=99 field, nothing happens: the dae= mon says =E2=80=9COK, I >> >> already have a store item with that =E2=80=98sha256=E2=80=99, so I do= n=E2=80=99t do anything.=E2=80=9D >> >>=20 >> >> Clearly, one has to be cautious with this, it=E2=80=99s easy to mista= kenly use >> >> the old source. >> > >> > Hmmm. I thought the sha256 was calculated over the derivation + >> > sources >>=20 >> What you=E2=80=99re saying is true of the hash that appears in /gnu/stor= e file >> name, but I was referring to the =E2=80=98sha256=E2=80=99 field of origi= ns, which is a >> different thing. >>=20 >> Ludo=E2=80=99. > > I think this is a bit of a problem even if it's expected: Often times we = can't > calculate the hash until it's downloaded and get a hash mismatch. The oth= er day > I rebuilt NixOS almost entirely on my machine and changed the revision on > Firefox to a new branch but didn't change the hash since I expected a mis= match. > > Needles to say I realized what happened when I checked Firefox's version.= I > think it'd be great to have a 'INVALID' hash we can use for development t= hat > just prints a mismatch and errors out like usual. Maybe this is possible = in > Guix, but it didn't seem documented and it's not possible in NixOS. The problem is that Guix cannot guess that the =E2=80=98sha256=E2=80=99 the= developer provided in the =E2=80=98origin=E2=80=99 form is actually wrong. Only the = developer knows. This is mitigated in Guix by the fact that we usually include the version string or Git commit ID in the origin=E2=80=99s file name, with pat= terns like: (define foo (let ((commit "deadbeef")) (package (name "foo") (version commit) (source (origin (method git-fetch) (uri (git-reference (commit commit) =E2=80=A6)) (file-name (string-append name "-" commit)) ;<=E2=80=93 ! (sha256 =E2=80=A6) =E2=80=A6)) =E2=80=A6))) The good thing with this pattern is that, when you modify the value of =E2=80=98commit=E2=80=99, you also end up modifying =E2=80=98file-name=E2= =80=99, thus triggering a re-download. So if you had forgotten to update =E2=80=98sha256=E2=80=99, y= ou immediately get a hash mismatch error. In practice, I=E2=80=99ve found this to be rather helpful. Additionally, =E2=80=98guix lint=E2=80=99 emits warnings for packages that = do not follow this pattern, hopefully making the problem that Pjotr describes less likely. Ludo=E2=80=99.