From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id wLFdA9zh0GEyvwAAgWs5BA (envelope-from ) for ; Sun, 02 Jan 2022 00:21:00 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id qOSpN9vh0GGVMgEAG6o9tA (envelope-from ) for ; Sun, 02 Jan 2022 00:20:59 +0100 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 2CE2A3A9B for ; Sun, 2 Jan 2022 00:20:59 +0100 (CET) Received: from localhost ([::1]:54318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3ngI-0001Ux-Df for larch@yhetil.org; Sat, 01 Jan 2022 18:20:58 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39338) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3ng5-0001UQ-5k for guix-devel@gnu.org; Sat, 01 Jan 2022 18:20:45 -0500 Received: from [2a00:1450:4864:20::343] (port=40944 helo=mail-wm1-x343.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n3ng3-0006Cc-92 for guix-devel@gnu.org; Sat, 01 Jan 2022 18:20:44 -0500 Received: by mail-wm1-x343.google.com with SMTP id j140-20020a1c2392000000b003399ae48f58so19199496wmj.5 for ; Sat, 01 Jan 2022 15:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=McYrhkjYNmiMgYCLxBwnQoS0DWpsa4/QMBS11JTQH8o=; b=d92ACsZwyhBMF+/f4dhWvnZ5KtzTrbZfjNvjPjsLpu+OLVENlwnwTn4Vg+163wzpG9 Xa7UsMrx8vyuDaNmH+YYYfNKolCqkntDoqRXtQmGoq4Kgn4hL4/6TD1KfCHixs2Y3Mlv Du/mlKfVvPZsgpHSlHeszr6amca2JwyvKGRg9IWYoDPLZIA4hvNq0chc/7982v/3KDLo xtuB2gZpzSnm8HnYLgsIpq9KtfRfloXvme8jZn9CrWzMsGZNXzbzvi08jID5S5k5dJwu 08nWPWwVOPUDfoRbNzXP+OxcIHMtf7bxYulddk6/0cYPOLN0++lSSpC9MlGyDgfxcMr+ nh7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=McYrhkjYNmiMgYCLxBwnQoS0DWpsa4/QMBS11JTQH8o=; b=pbFaLAXbrL17cH7UFw2A6TWZPJWj+JSuACbj6F8oTHx41tz3iQe5GuPg51W8VA95M3 YPF2dOGYdrpcGTv7VpplyXHzZgMH+l3KfeLRO3+mQty2EURbe38aQwVuXTeA8uCgbSW9 Bv/rGb09ZwhsO6TbuR4wbb4EuX64Qln9I71j2mi7wbbBNzehTXRpCK6QbK8gvgtR7eZ8 l2WGbbygc01oD83OQW+IVrQ30QSDBiqFii5PmcaQabUJDFz22DA7NdhbaIqYI28TUtnd HJLSS7VH9WZi3tkF1Das+P17Nv5blqd2KLpidgikG6vDAnm0c04G2Js2A/Br4HovmUYn yfqw== X-Gm-Message-State: AOAM533RqIQQ+dgaS3NcHIV2A/vGupULbrk+ZwUGfW+VcTr2r1MhTZG1 e/Dqegb3iJyteLSnHJ3rEic= X-Google-Smtp-Source: ABdhPJxeWqKMkRS0gwjs02IuhL8b9q5OAVr3GN16iBzx6NFKSZDWRMTthAi21yKDtJZC3CCjBlgDZw== X-Received: by 2002:a7b:c058:: with SMTP id u24mr24745005wmc.90.1641079241266; Sat, 01 Jan 2022 15:20:41 -0800 (PST) Received: from nijino.fritz.box (85-127-52-93.dsl.dynamic.surfer.at. [85.127.52.93]) by smtp.gmail.com with ESMTPSA id p13sm30424723wrr.37.2022.01.01.15.20.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 01 Jan 2022 15:20:40 -0800 (PST) Message-ID: Subject: Re: On raw strings in commit field From: Liliana Marie Prikler To: Mark H Weaver , guix-devel@gnu.org Date: Sun, 02 Jan 2022 00:20:39 +0100 In-Reply-To: <87tuenky2x.fsf@netris.org> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <87k0fm7v3k.fsf@netris.org> <871r1smdu6.fsf@netris.org> <87tuenky2x.fsf@netris.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::343 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::343; envelope-from=liliana.prikler@gmail.com; helo=mail-wm1-x343.google.com X-Spam_score_int: 6 X-Spam_score: 0.6 X-Spam_bar: / X-Spam_report: (0.6 / 5.0 requ) DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1641079259; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=McYrhkjYNmiMgYCLxBwnQoS0DWpsa4/QMBS11JTQH8o=; b=e8aAPuLgA2Mr9zlbEw2gLw1G3LsnRbvLOLGKQXI8vN/CG8idgAZoGrM0s7NiESC/cUgaMD B9Z4QdN0QbmXhX62uNP2aSQ4oasJG7hFROXbjTXELJYk9BW7hKbX9hW1hxU+J/4orfMh9C K5/LQUUihxNxl9Da0prVNmzqTMdNdFpCbg7Z/P3wdMrUQBj4NwgWCUw8eJhofLbCpfC25Y XZcqUgquKk2WJHePaNmefYLkp1HPM7oZy2b8wHFV1NMgIt3t6+fsuwSAnLymj+CtundtC+ NK3XBYU23Morg8utvVHJAdaCi3Q4xw6itIJtZyAcpYAdn6UadzDIodWib7w1ng== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1641079259; a=rsa-sha256; cv=none; b=dYuCEs2HNtl9QVT+U5npZBmG/F03zFMdELvOvPBLu0Nhb7uhrDdZiedDBlXQDHT4uUDTZR QoCkiCZ2J5oeG6mzuP3AtU6b4ozn0cmzVl6jPymbZCe9vaqqBccOSOkga2WHq5QWyGqhOq xlgQWJkUkUNvA92UbRJruTb6fJEuGMIA3WvIiFVHMEOWU+1lPDCTM8l50giLlmW0uFY8BC qiUoASVDi8LGxkKv8JzzMjz4e0kf5Ck934kddQwHSSEy9Dh68pBAr5KLOT/MuQ41ZCXE/L uEcZlhfwuCuTgGBYKEqb7E+vkSb4qZPUNFSSCIg2cAIRq4dO9n+zfXseWJXtBw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=d92ACsZw; dmarc=pass (policy=none) header.from=gmail.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" X-Migadu-Spam-Score: -4.28 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=d92ACsZw; dmarc=pass (policy=none) header.from=gmail.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" X-Migadu-Queue-Id: 2CE2A3A9B X-Spam-Score: -4.28 X-Migadu-Scanner: scn1.migadu.com X-TUID: 3otJADYt56Hi Hi, Am Samstag, dem 01.01.2022 um 15:19 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > > Am Freitag, dem 31.12.2021 um 20:41 -0500 schrieb Mark H Weaver: > > > I disagree with the last line above.  What makes you think that > > > I'm presupposing that the tag does change? > > > > > > There's a difference between "presupposing that the tag does > > > change" and "not assuming that the tag will not change".  Do you > > > see the difference? > > I'm pretty sure ¬assume(¬X) = assume(¬¬X) in this concept. To correct my own typo here, I meant context, not concept. > No, that's certainly false.  On the left-hand side of that equation > there is an absence of any assumptions, and on the right-hand side > there is the assumption that ¬¬X is true. > > Perhaps something is getting lost in translation between our > languages. You are not a tabula rasa. By the time you push a commit or even by the time you submit it to the mailing lists, you have already made a bunch of assumptions, some of them just more implicit than others. Assuming you care enough to make an informed use of the raw commit pattern rather than just copying it from elsewhere, this holds even more so. > > > > > > > However, if we are always talking about more than one possible > > > > "1.2.3" (with the included future tag that we have yet to > > > > witness), we lose the basis by which we currently assign > > > > "1.2.3" as the version > > > > > > I see what you're getting at here, but still I disagree.  Our > > > basis for associating version "1.2.3" with commit XYZ is simply > > > that upstream had indicated that version "1.2.3" was commit XYZ.  > > > That historical fact is immutable. > > History is a social construct, it's not immutable. > > I agree that /our knowledge of history/ is a social construct, and > thus mutable, but that's not what I was referring to here.  I was > referring to the facts of what /actually happened/ in the past, which > is admittedly unknowable to us (especially in recent times). We'd have to go into metaphysics in order to debate that and I'm sure you could chase that rabbit hole to find an answer that works for software version control, but at the same time we are dealing with an even larger field of unanswered questions at that point and not making any advancements to the problem we're actually trying to solve whatsoever. > > > > > If upstream later indicates that version "1.2.3" is now commit > > > YYZ, I don't think that invalidates our basis for continuing to > > > associate version "1.2.3" with commit XYZ.  The aforementioned > > > immutable historical fact still remains our basis and > > > justification for making that association. > > I'm pretty sure it does, particularly to a future observer who may > > not have the luxury of a history to distinguish that record from > > one in which a malicious committer linked those versions and tag > > together and then no one bothered to check. > > It's a valid point.  However, your denial of the existence of any > immutable historical facts (which is somewhat defensible) is starkly > at odds with the fundamental principles of GNU Guix and its core > goals. > > I can understand your desire to have "FOO@1.2.3" in Guix correspond > to the most recent announcement from the upstream FOO project on what > they consider version "1.2.3" of their package to be.  This is > obviously a desirable property for a package manager to have. > > The problem is that it's incompatible with properties of Guix that I > consider to be far more important.  I don't want the meaning of > "FOO@1.2.3" in Guix to depend on what time it is when I ask the > question.  I want it to mean the same thing tomorrow that it means > today.  Reproducibility requires this.  It requires some notion of > immutability. > > I don't see how to reconcile Guix's core goals with your apparent > goal of having "FOO@1.2.3" match upstream's latest idea of what > "1.2.3" means to them, without abandoning the use of package version > numbers in Guix altogether. > > We might simply want different things from a package manager. > De gustibus non disputandum est. I think you are (intentionally or not) ignoring multiple key assumptions here, that we can work with. Some because we're dealing with software, some because we're working with Guix. For instance, the assumption (you might call it "fact"), that Guix can identify an origin by a combination of filename and hash. Or the assumption that version numbers are monotonically increasing and typically not reissued. When you claim for a specific git-reference that you need to prepare for the occasion of a tag being overwritten, you are making an assumption that such an event will indeed take place in the future and justifying your action based on said assumption. When I claim "yeah, GNOME has been around for more than twenty years and they're pretty adamant about versioning", I am doing exactly the same. However, notice how from my assumption it logically follows – as long as said assumption remains valid – that there exists a single release 41.0 which I can refer to (by tag), but from yours – again, as long as it is valid – it follows that there is no single version N that you can refer to by whatever commit you have. Now what if I'm wrong? If I am indeed wrong and GNOME 43 is tagged twice or even thrice, I'd be willing to use git-version for all GNOME stuff that we take from git. I'd also be willing to move to git origins for GNOME stuff if mirror://gnome becomes unreliable. But what if you're correct? Are you willing to use git-version for every single git-reference out there?