From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GPe1CFrTyl6kPQAA0tVLHw (envelope-from ) for ; Sun, 24 May 2020 20:04:42 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id OGWfBFrTyl7JZgAAB5/wlQ (envelope-from ) for ; Sun, 24 May 2020 20:04:42 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id D085894030A for ; Sun, 24 May 2020 20:04:41 +0000 (UTC) Received: from localhost ([::1]:45686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jcwrQ-00043P-Ry for larch@yhetil.org; Sun, 24 May 2020 16:04:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:40672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jcwrI-000436-B8 for guix-devel@gnu.org; Sun, 24 May 2020 16:04:32 -0400 Received: from mail-ua1-x944.google.com ([2607:f8b0:4864:20::944]:42043) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jcwrH-0005Ju-1Q for guix-devel@gnu.org; Sun, 24 May 2020 16:04:32 -0400 Received: by mail-ua1-x944.google.com with SMTP id 36so5496759uaf.9 for ; Sun, 24 May 2020 13:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=g4YrMT7nCvtuU9kt9Q57b0WpYvw4IgVciS7ry5X29vA=; b=PZUj5OWv8LpiYClYYI9mLEJgzAXPo0LqvSONJXiAlFlsGalxyFD9Lqo5KHnvLLf7Hi Qn8zGJ7mB+148TPcUlU6Fnqu+h+oIaCbq/D3trjiGnGwLTorT1AwVH5gfHA/JJ/gdVc6 w66FE+nIWyk3TDS3Cn4Vj5P0iQd+h0XcbB3WG2PD+xfwHK55bBgKsEO01EuTh7U1aN3Z buAgokiS1HNwASvI0FXMtlIRYzfq4rtE6U6W6BO1KlfmWJScVOgAqP7IHM4cYQzu7sP3 jaCr/CEiF2OoWPwLix9ChUqPKCwdete50vI3cKaBkIZiyFxMGx1o9A9b09NbmPZpoidY H4ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=g4YrMT7nCvtuU9kt9Q57b0WpYvw4IgVciS7ry5X29vA=; b=rvSBHCzSYPn1xYHmUOIAJWlCWccm4wGxUure/R4tzsvNv0YFCNveJwV60iUzyysVvG W/xRRNNuMviyk1PwmgY7AEHI/ZVzriy73ofM5ZICI3V2YsewTlHANNvE8+b7UxBCXFLA aLOyFCzlIvF/eOZVc220c8VZGNJ49YDoLPVSS/PT0n3vt8/SqHu+PqGnwRTwFRL/dFdZ CMd/K8+MnTUQDwaREkRhMZSLZkbWXgChD/0XLYei464g4ZJXfsmO9KsSZ5OiqCKKr7Df nZ2yYSsaisL9WjOyG9IrZQ0VnVPjsNyYhNNoo7x2c+gG9vRATMda2YSdqpD1zY2YTtMh B2ag== X-Gm-Message-State: AOAM5332Q/12S+WiKczCB6AlyG99ayfMN1Hfv2EIwtabaD13gat/UUVF hImR9oNcm2YI/mS45Olarasfei0kxudPzv2NnNs= X-Google-Smtp-Source: ABdhPJziP0ryfb5d4srYGayZW030YhFpKwvl2DmxcBBIrT0rG7fpIMca5zpcAK/HXua3JPcu1AA3ZZCeYlFxTA1VF0g= X-Received: by 2002:ab0:6347:: with SMTP id f7mr15070044uap.130.1590350669356; Sun, 24 May 2020 13:04:29 -0700 (PDT) MIME-Version: 1.0 References: <20200306091524.5044.11103@vcs0.savannah.gnu.org> <20200306091525.E8A1621163@vcs0.savannah.gnu.org> <87o8t9lfci.fsf@devup.no> <871rq5bjzf.fsf@ambrevar.xyz> <87lfodl6u5.fsf@devup.no> <87tv2vgdlg.fsf@gnu.org> <87lfo72b8i.fsf@ambrevar.xyz> <878shv3dzz.fsf@nckx> In-Reply-To: From: Josh Marshall Date: Sun, 24 May 2020 16:04:17 -0400 Message-ID: Subject: Re: best practise between git-fetch vs url-fetch? To: Jack Hill Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::944; envelope-from=joshua.r.marshall.1991@gmail.com; helo=mail-ua1-x944.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel , Brice Waegeneire Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (rsa verify failed) header.d=gmail.com header.s=20161025 header.b=PZUj5OWv; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Spam-Score: 1.09 X-TUID: lQDwzCQU4yV4 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 wrote: > > On Wed, 13 May 2020, Tobias Geerinckx-Rice wrote: > > >> --with-commit > > > > Yes, this is niice. =E2=99=A5 > > > > For the sake of argument=C2=B9, though, so is --with-source=3D > supported upstream tarball dot tar>. > > > > Somehow erasing that hard distinction is the real winning move. > > > > Kind regards, > > > > T G-R > > > > [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 constraint= s > (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 whe= n > 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 th= e > 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