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

[Ludovic Courtès]

Hi,

Robert Vollmert <address@hidden> skribis:

> On 29. Jul 2019, at 18:10, Ricardo Wurmus <address@hidden> wrote:
>> 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?
>
> I would suggest that they specify the archive type, and either
>
> - repack the archive to a standard format, e.g. .tar.gz (this should then also
>   apply to sources that are local directory trees)
> - unpack the archive to a directory tree

Note that ‘git-fetch’ & co. currently produced fixed-output derivations.

If ‘git-fetch’ were to systematically repack to a tarball, we’d
introduce a dependency on tar + some compressor, which is not always
desirable.

> An alternative change that would make the whole setup a bit less confusing
> would be to factor all the “standard” build system stuff out of 
> gnu-build-system
> and into a base-build-system that provides source unpacking and phase handling
> and nothing else.

I agree that this would be an improvement.

Ludo’.