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

[Josh Marshall <joshua.r.marshall.1991@gmail.com>]

Hello all,

Continuing my Sunday catch-up, I'd like to kick the tires on this.

Tarballs seem to have the following:
+ Faster to build
+ Faster first time download
- Larger downloads for smaller changes
- Autotools are pre-built, negating bootstrapping
- SWH not yet supported (https://forge.softwareheritage.org/T1352)
+ Fewer package dependencies\
+ Can use alternative source versions via `--with-source` -- more
likely for each to work, but fewer options

Git seems to have the following:
- Slower to build
- Slower first time download
+ Smaller incremental downloads
+ More complete bootstrapping
+ SWH support is working
- Adds extra dependency on git
+ Easy use of alternative commits via `--with-commit`

Practically, these options are highly similar, with git having some
edge when it comes to bootstrapping the software more completely, and
avoiding using as many non-source executable things.  But that is
extendable to tarballs as well.

What it comes down for me is that git offers a more coherent history
of a piece of software all in one location.  Tarballs are snapshots in
a software's history, and I'd prefer to just have the entire history
already in one managed and organized location.  That is one things
tarballs can't practically accomplish.

I am also for having a de-factco, soft suggestion that packages use.
I think git-fetch is ever so slightly the better option, and so should
be a "default" recommendation over url-fetch.  That being said, I am
more in favor of having a default than what that default is.

On Thu, May 14, 2020 at 12:16 PM Jack Hill <jackhill@jackhill.us> wrote:
>
> On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote:
>
> >> --with-commit
> >
> > 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,
> >
> > T G-R
> >
> > [1]: Obligatory <https://xkcd.com/1432>.
>
> 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.
>
> Best,
> Jack