Hi, Robert Vollmert <r...@vllmrt.net> skribis:
> On 29. Jul 2019, at 18:10, Ricardo Wurmus <rek...@elephly.net> 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’.