Re: best practise between git-fetch vs url-fetch?

[Ludovic Courtès]

Hi,

Jack Hill <address@hidden> skribis:

> It seems a bigger problem is when the build method for the git
> repository and release tarball are different. In many packages this is
> because of the pre-generated autotools build system in the release
> tarballs. Should we bootstrap the autotools build system even when
> building from a release tarball? As I understand it, autotools has
> historically been treated this way in part to allow building on
> systems without the right version of autotools, but is that really a
> problem in Guix? Why should it be treated differently than other
> pre-generated artifacts which we rebuild?

You’re pointing out a contradiction here.  On one hand, we take
advantage that Autotools-based programs require nothing but a POSIX
shell and make to be built, unlike most other build systems, which
greatly simplifies our dependency tree.  On the other hand, we’re
striving to build everything from source, and Autotools-generated files
look like elephants in this room.  Debian has been dismissing those
files for a long time.

Probably we should aim towards not using pre-built Autotools generated
files and, by extension, probably not using pre-built tarballs when VCS
checkouts are available.

It’s kinda happening on leaf packages, often upstream developers people
don’t bother running “make dist”.  It’ll take some time before tarballs
disappear and needs some thought in particular from a bootstrapping
standpoint.

> Another improvement we could make here is improving the message about
> Software Heritage in guix lint. Most of the other messages it emits
> are things that the author of a package should consider improving. If
> the Software Heritage message is less actionable, let's make that
> clearer so that people don't think there is a problem with their
> package definition.

What message would you suggest?

Thanks,
Ludo’.