guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git-fetch origin output is read-only - and reproducibility


From: Ricardo Wurmus
Subject: Re: git-fetch origin output is read-only - and reproducibility
Date: Mon, 29 Jul 2019 18:10:39 +0200
User-agent: mu4e 1.2.0; emacs 26.2

Hi Robert,

>> On 29. Jul 2019, at 17:49, Ricardo Wurmus <address@hidden> wrote:
>>> currently, when using the git-fetch origin, the resulting source will have
>>> all files read-only.  Further phases trying to do reproducibility patches 
>>> 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’s a little annoying when switching from
>> a tarball to git-fetch because you’ll have to add a phase that makes 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 figured
> out that such things were left to the build system. Couldn’t 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 “svn checkout” 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’ll get to
reuse the “unpack” phase, which conveniently checks if the source is a
tarball.  In the case of Java archives it doesn’t do the right thing,
because it doesn’t know about Jars, so the ant-build-system overrides
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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]