[Top][All Lists]

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

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

From: Jack Hill
Subject: Re: best practise between git-fetch vs url-fetch?
Date: Thu, 14 May 2020 12:16:29 -0400 (EDT)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote:


Yes, this is niice.  ♥

For the sake of argument¹, though, so is --with-source=<actually released and supported upstream tarball dot tar>.

Somehow erasing that hard distinction is the real winning move.

Kind regards,


[1]: Obligatory <>.

Heh, I'll take the bait. I also really appreciate how easy we make it for people to exercise their software freedom and run modified software. How best to make that possible and balance it with other usability constraints (e.g. mirror:// urls should be more robust) may vary by package, so I agree with Leo that some discretion is needed. However, that's not to say that I wouldn't appreciate some guidance as to our default preference when there is no package-specific reason to prefer one way over the other.

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?

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.


reply via email to

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