From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: git-fetch origin output is read-only - and reproducibility Date: Mon, 29 Jul 2019 18:10:39 +0200 Message-ID: <87ftmo7reo.fsf@elephly.net> References: <20190729165743.04e6a516@scratchpost.org> <87k1c07sdf.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:56196) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hs8EY-0002qM-7S for guix-devel@gnu.org; Mon, 29 Jul 2019 12:10:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hs8EX-0007Vo-5I for guix-devel@gnu.org; Mon, 29 Jul 2019 12:10:46 -0400 Received: from sender-of-o51.zoho.com ([135.84.80.216]:21213) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hs8EW-0007US-Pt for guix-devel@gnu.org; Mon, 29 Jul 2019 12:10:45 -0400 In-reply-to: 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: Robert Vollmert Cc: guix-devel@gnu.org Hi Robert, >> On 29. Jul 2019, at 17:49, Ricardo Wurmus wrote: >>> currently, when using the git-fetch origin, the resulting source will h= ave >>> all files read-only. Further phases trying to do reproducibility patch= es have >>> to manually chmod in order to be able to patch. >>> >>> Can we change that? For example change what this origin does or change= what >>> the build systems do by default? >> >> I think this would be good. It=E2=80=99s a little annoying when switchi= ng from >> a tarball to git-fetch because you=E2=80=99ll have to add a phase that m= akes all >> files writable. >> >> This would probably have to be changed in the unpack phase of the >> gnu-build-system, which copies files recursively when the sources are a >> directory (instead of a tarball). > > At the risk of getting slightly off-topic, I was very surprised when I fi= gured > out that such things were left to the build system. Couldn=E2=80=99t the = source/origin > abstraction consistently refer a directory tree *or* a tarball? Almost anything can be a source. (Even #F is a valid source.) The origin methods only operate on their arguments and fetch whatever has been requested. This might be a single file (a tarball) or it could be the result of running =E2=80=9Csvn checkout=E2=80=9D or anything else. These fixed output derivations that are generated from origins only care about obtaining *something* that has the provided hash. It is up to the builder to do something with whatever the source really is. Most build systems inherit from the gnu-build-system, so they=E2=80=99ll ge= t to reuse the =E2=80=9Cunpack=E2=80=9D phase, which conveniently checks if the = source is a tarball. In the case of Java archives it doesn=E2=80=99t do the right thin= g, because it doesn=E2=80=99t know about Jars, so the ant-build-system overrid= es that phase, etc. Dealing with sources sometimes requires special knowledge and the build system might be best equipped to employ that knowledge. What would you suggest the fetchers implement to guarantee that the sources will always be of some expected form? -- Ricardo