Hi Robert,
>> On 29. Jul 2019, at 17:49, Ricardo Wurmus <[email protected]> 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
