From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id IJwsNe9uvV50YAAA0tVLHw (envelope-from ) for ; Thu, 14 May 2020 16:16:47 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id OOVYL+9uvV4/AgAAbx9fmQ (envelope-from ) for ; Thu, 14 May 2020 16:16:47 +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 4CC6694053D for ; Thu, 14 May 2020 16:16:47 +0000 (UTC) Received: from localhost ([::1]:59548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZGXO-0008Vu-0B for larch@yhetil.org; Thu, 14 May 2020 12:16:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZGXC-0008UM-Lu for guix-devel@gnu.org; Thu, 14 May 2020 12:16:34 -0400 Received: from minsky.hcoop.net ([104.248.1.95]:60128) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZGXB-00054q-ER for guix-devel@gnu.org; Thu, 14 May 2020 12:16:34 -0400 Received: from marsh.hcoop.net ([45.55.52.66]) by minsky.hcoop.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jZGX7-0002oT-LD; Thu, 14 May 2020 12:16:29 -0400 Date: Thu, 14 May 2020 12:16:29 -0400 (EDT) From: Jack Hill X-X-Sender: jackhill@marsh.hcoop.net To: Tobias Geerinckx-Rice Subject: Re: best practise between git-fetch vs url-fetch? In-Reply-To: <878shv3dzz.fsf@nckx> Message-ID: 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> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="925712948-498339204-1589471654=:5735" Content-ID: Received-SPF: pass client-ip=104.248.1.95; envelope-from=jackhill@jackhill.us; helo=minsky.hcoop.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/14 12:16:31 X-ACL-Warn: Detected OS = Linux 3.11 and newer X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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@gnu.org, Brice Waegeneire Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=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: 2.49 X-TUID: Z1OBPVHLpWNr This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --925712948-498339204-1589471654=:5735 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: 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= 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 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 --925712948-498339204-1589471654=:5735--