From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms13.migadu.com with LMTPS id kL9sKhUF8mZQXQEA62LTzQ:P1 (envelope-from ) for ; Tue, 24 Sep 2024 00:17:25 +0000 Received: from aspmx1.migadu.com ([2001:41d0:303:e16b::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1.migadu.com with LMTPS id kL9sKhUF8mZQXQEA62LTzQ (envelope-from ) for ; Tue, 24 Sep 2024 02:17:25 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b="Ukh/g88l"; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1727137045; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=T9WJccGNyWwTRtm+1pR1gJiMrtdTiZ+zQMhFiO+rwVw=; b=gFENhO1rL7qPelm1XQIz2nBD8MzZaXohqXh6atyEKyoXSZvuTlU4d5xQZrYTEAzbk4VSRW bqssXE47eyPpaFbQErztQlH2UFdTkdP8go8n6YaLtK13QwTv95eKPPon9XIVSbXVatxD5X 0n7/xxs93/cJRdauyHdRh91k6xOmFZXBNpttzpGC5dUKBNjiDqTfoGgY6Cz5f+e+am5pAV ovCxihO/aXp8cfzIW29P+IIPoHm2FBE/9sTBYpy66Ea6VNDkn7ZzjyKE4X92UX5MD83Ilu YALz7HWphusBxjrTDUpFGseLA/djDMu5du4LvDtB76dgD9bWBNaspczmWVUVDw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1727137045; a=rsa-sha256; cv=none; b=IIiMVUffvNDT36YjkFAOYScgGH8U7ll35KO1MfI4yoblDRhs1DE3tKHvN12QNFD/zvVckf 2sqoOkvkPu1t0b8wRAHT/SYsAPISBs/lZI/MQ70HBChLM7jc2SiEmrUoGxQBpZgYsT4cS9 AiC+y2KyJMrkyYcLElRrWB5C8P0pnkbKV4R01M02jk4vCGO/Ig0gTTPiAG/2MX1BXkOspJ XoC95lSlhSHMo2htYWcmLk0BU3KABUwctVBotNrzrGjS3aZrI2dq0LYM3N1io1ysquLeJH FlSxk81Lo7uZenteMk+uYft11oAqMloV3Qdp0YJZNNvqLOokBFR5/cPAhWTrZA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b="Ukh/g88l"; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" 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 57390D718 for ; Tue, 24 Sep 2024 02:17:25 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sstEP-0006AK-VC; Mon, 23 Sep 2024 20:16:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sstEO-0006AA-Ab for guix-devel@gnu.org; Mon, 23 Sep 2024 20:16:40 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1sstEL-000400-Uy for guix-devel@gnu.org; Mon, 23 Sep 2024 20:16:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1727136993; x=1727396193; bh=T9WJccGNyWwTRtm+1pR1gJiMrtdTiZ+zQMhFiO+rwVw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Ukh/g88lON2O0fUcjjeZkNplXLmVbkc0NdsUiNFslK5xVlcxE2lagIU8V9SNn+68X QK8CSkCZ4rnWIFq6TMnaWBrxYZup7EYxikVWrRgobu0QYtdci7tHBwRl9RfXJisxts W3lIKjfYqJeSkn1l53pyoe2KCIyIhBwjFHXsFPirwIi5lfnHB6dv+tGw1JFIm5qS51 bK2TZxyWwHYmug4E66r+U3ucj7hwvBV8HzGHnZFTlbavE4E3JRElFzCNvZ1G0kUcb7 aJP86Tx8XaDpHBF7s+O+U9V60J2v4sgFB/VydInflgHy9OL/EBryjv0sGpWuK3iG0v OaQp/u2ZqYyKw== Date: Tue, 24 Sep 2024 00:16:29 +0000 To: Suhail Singh From: Kaelyn Cc: Vagrant Cascadian , Andreas Enge , Konrad Hinsen , Simon Tournier , Tobias Geerinckx-Rice , guix-devel@gnu.org Subject: Re: Rebuilding a package after removing a build step Message-ID: In-Reply-To: <87cykui6aa.fsf@gmail.com> References: <50CD9D3B-BAE4-4D11-8AF6-906649D74FF9@tobias.gr> <877cb6s12t.fsf@gmail.com> <87r09ajr2g.fsf@wireframe> <87cykui6aa.fsf@gmail.com> Feedback-ID: 34709329:user:proton X-Pm-Message-ID: 0541529a33645e4c1d7b0700a0ca3195a0afd070 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.16; envelope-from=kaelyn.alexi@protonmail.com; helo=mail-4316.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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_FROM=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -4.11 X-Spam-Score: -4.11 X-Migadu-Scanner: mx13.migadu.com X-Migadu-Queue-Id: 57390D718 X-TUID: CWqsMGitnXek On Monday, September 23rd, 2024 at 11:17 AM, Suhail Singh wrote: >=20 >=20 > Vagrant Cascadian vagrant@debian.org writes: >=20 > > Rather than picking an arbitrary incremental number, I have in the past > > used something based on the results from git describe... e.g. in my > > current checkout of guix: > >=20 > > $ git describe --match=3Dv1.4'*' > > v1.4.0-142685-gfc059c66cf > >=20 > > e.g. 142685 commits past v1.4.0, with the commit fc059c66cf > >=20 > > That should usually end up in the correct order, although sometimes > > there are surprises. For example, I had to specify --match otherwise it > > picked v1.3.0 for some inscrutible git merge-ordering reason. >=20 >=20 > That seems like a useful and fairly generally applicable strategy. Any > reason as to why something like that (which allows for additional > optional arguments such as "--match-v1.4'*'") shouldn't be used as the > default (as opposed to manual revision numbers)? There are a few problems with using that as the default: * Generating that version number requires the git source repository; a pack= age definition requires a fixed version number that can be computed without= ever downloading the source code, since it is part of the package metadata= (though such a strategy could potentially be used by e.g. "guix refresh -u= " though that would require a consistent way of setting the revision in the= package definition such that the tool knows what string to change). * Using something like "git describe" to compute the revision would either = be specific to packages which are built from git checkouts (i.e. built into= the git-version function) or recipes for obtaining similar output would ha= ve to be written for the other version control systems for which support is= desired. Closely related (but optional if the actual value of the revision= is treated more loosely) is that some packages would need the "--match" fl= ag to generate revision numbers from the correct point and the match expres= sion would have to be updated when the "base" version for the revision coun= ting changes. * Within git repos, "git describe" only works if there are (annotated) tags= for "git describe" to base the revision number on. If the source repo does= n't use tags, the approach won't work and manual revision numbers would sti= ll be needed. Likewise, if the repo doesn't use annotated tags or uses anno= tated tags for purposes other than tagging official releases, the chosen ta= g used for the revision (even at a given commit, if an older commit is give= n a new tag) may not be consistent without using a sufficiently specific "-= -match" flag. I also want to say that the above points are primarily about automatically = using "git describe" to dynamically generate a revision. I do not want to r= ule out or discourage ideas for ways to make use of "git describe" more con= venient as a source of truth when determining what value to use for the rev= ision. I think it could be quite useful especially for updating packages or= doing local development. Cheers, Kaelyn >=20 > -- > Suhail