From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id qD1FNAB2zmEg6AAAgWs5BA (envelope-from ) for ; Fri, 31 Dec 2021 04:16:16 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id sAXxMAB2zmGINQAAauVa8A (envelope-from ) for ; Fri, 31 Dec 2021 04:16:16 +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 573B0C8A5 for ; Fri, 31 Dec 2021 04:16:16 +0100 (CET) Received: from localhost ([::1]:55936 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n38Ot-0001Kb-Gw for larch@yhetil.org; Thu, 30 Dec 2021 22:16:15 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35946) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n38Nr-0001KP-FV for guix-devel@gnu.org; Thu, 30 Dec 2021 22:15:11 -0500 Received: from [2a00:1450:4864:20::444] (port=41709 helo=mail-wr1-x444.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n38Np-0004Ux-Lu for guix-devel@gnu.org; Thu, 30 Dec 2021 22:15:11 -0500 Received: by mail-wr1-x444.google.com with SMTP id a9so53729650wrr.8 for ; Thu, 30 Dec 2021 19:15:09 -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=klu32l/oQ8bM0LZgiQNEBoIm3qDuZRCXDf2g4ykJESY=; b=k08he7LiVSNxAJ+vu0aGdmh6zkBFWowkeKv+pGAm+amImyEkgqJZ5JI5x0Qwf25krc sXX8x2s/35iY7VPuAng+QxDLjrR8DJUvFkfHMWaYXd2OSRP3He7HGiRntet3HAhRRMv7 frp86jfxc8C2lIqVvbejpA6x0r5qew1x+cXKzo3p1AAKJsN0PvfGaJsjI6sMV5160VHm gqKpa+GGiAJywkWQgiq7/w4rIL/KlBSITY6azJ1oFGqDdA0e7hfWEw9J8dBFVUmjLaev MU24SGbCO3zEL0el4FCASIX4TaMpDd+xa3pxjY19uqt2lm5/n6tj7AK9GG6/+aMgQTEE MyxQ== 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=klu32l/oQ8bM0LZgiQNEBoIm3qDuZRCXDf2g4ykJESY=; b=IFwhIJ5Hj1XPrTA5D7l2PArwHcgh/0mt6ukkxlDPFn/nYJn+6R5sewEjpN3PT58Klj 3YB4O69ysefwa3DnUFKNM+zGrH0CjRSxXxZMYPUNNLquAcspW7wKKbSWwUy9A4UxLjsG CXiB0ndrMacBiutox+pn3ahccC4xoum4ZmfQLc/mUUjjPxtagxuQvtmKTRln+KMcJSFu kl8WX81UX7pbYU2DWVkVHRoILycnc4W3bxk51Dgfa8BePv98feNwttKtwInD8EeNsWGl KlV+JSMiEGbErTkm2CtRqXJBSlXWx2fo3PmuYZMREFMH+oR/+UkKD43ZUHhpnAxEFtPa iOJw== X-Gm-Message-State: AOAM5317TwkwrVa+ATO+ESmurpKuglPp6tH5U1T53tMVLt9TBltRV9f1 2Wl7yL2GWS9i20ua+/Sr2mG79jPf0j/vLg== X-Google-Smtp-Source: ABdhPJxBCe3MR7np1yutE4LBfy0gaw06vJoekL0QYyXtkyO3Dnxl7tS9CZPxn4wM0qDAskLah/8qnw== X-Received: by 2002:a05:6000:18cd:: with SMTP id w13mr144277wrq.199.1640920507945; Thu, 30 Dec 2021 19:15:07 -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 1sm28837857wry.33.2021.12.30.19.15.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 30 Dec 2021 19:15:07 -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: Fri, 31 Dec 2021 04:15:06 +0100 In-Reply-To: <87k0fm7v3k.fsf@netris.org> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <87k0fm7v3k.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::444 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::444; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x444.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=1640920576; 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=klu32l/oQ8bM0LZgiQNEBoIm3qDuZRCXDf2g4ykJESY=; b=jVUA/14ohbHL+8C4Zkn++b+M1XaKtcbvkJKHXyu0CM21c3cvwRYk0O7q6eKcQaw0gLMZrO RHLs5sNdUr3fINVMqY9WjRefSsMkgmTiqPo4BbSQT97456shr6oHLKrCdG7fM/eJRry4d5 d0QSS/Kv5XS/Mpsx1caatPN4+/IQNp05mcou4oa68zH3/dThSqdxyvHwKNfs5M+2pGq2SY 4rkcxVfUwiRgO8MThuzeCJCSAcul41Fyb+oy219Cft2IKDyGzSPcTIpQtpN2MtQ4996d9E wU+Ia1qdaF67ES6lzizFzlVItrHH1bF/e+IGz/OskmOVDvZHo4DytfVBEoqlGA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640920576; a=rsa-sha256; cv=none; b=bRxGC0QAJUvj/oNSWpcvOBYtekok/m51DTCEFvYZJT4OlpUzwPyP4AQKyhN1p877PkjkCn MhNI6QzgXGkLSYy5cjupjHetpq6BP+mX5a2sTf8kOAo0mwzfyjvp28kTJpOxxX3woTyOJv d/T8sCk3gD3ArUgFed/C6VyU6RDGp02WDO8UXdEc8wrzc2DedGWpv5kdDs9dksWD159uT3 R2fX2DkgbNbTP7KZgW39S76VVkRy4F89kWnrczguqTrsEKfMU246tEYrcSFDY88KUPxyrq ZoGzqoaZIYWPYnIZ4p8gxCVhodLhgnSDecxHJiygTeqE7Y0Fr5fu28c/+q6x/Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=k08he7Li; 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=k08he7Li; 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: 573B0C8A5 X-Spam-Score: -4.28 X-Migadu-Scanner: scn1.migadu.com X-TUID: MuAf/UVe9dGG Hi Mark, Am Mittwoch, dem 29.12.2021 um 20:13 -0500 schrieb Mark H Weaver: > Hi Liliana, > > Liliana Marie Prikler writes: > > It should be noted, that in the case of moving or deleted tags, the > > assertion Guix "1.2.3" = upstream "v1.2.3" no longer holds. > > Agreed, but I don't think that assertion should be our top priority. > > For purposes of Guix's core goal of enabling software to be reliably > reproduced in the future, the most important property to preserve is > that 'Guix "1.2.3"' should remain forever immutable. > > An obvious corollary is that if upstream mutates the meaning of > 'upstream "v1.2.3"' over time, then the equation above will become > false.  That would be an unfortunate result of upstream's actions, but > it's exactly what _needs_ to happen to enable Guix to be reliably > reproducible. > > If I perform an experiment with Guix "1.2.3" and publish the results, > and someone later wishes to reproduce those results, they will want > precisely the same 'Guix "1.2.3"' that was used to perform the original > experiment, and not whatever version of the software upstream is now > calling "v1.2.3". I agree with you so far, though with some nuance. Obviously, when travelling back in time, we want Guix' "1.2.3" to be whatever it was by that point, but on the other hand, we also want a recently pulled Guix to have a reasonably recent "v1.2.3" if it claims to have "1.2.3". So we have two proposals at odds with each other, with only the origin- hash to determine which interpretation to prioritize. > The simple fact is that the way Ricardo wrote the 'guile-aiscm' package > is the right way to ensure that it can be reliably reproduced in the > future. And here I disagree. This reasoning presupposes that we have to ensure that the package still points to the same commit if the tag changes, which itself presupposes that the tag does change. 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 (instead of using git-version, as we expect it won't be "1.2.3" at some future point). This scheme only makes sense when it doesn't make sense and when it doesn't make sense it makes sense. > Guix packages that refer to git _tags_ may cease to be reproducible in > the future if upstream mutates or removes those tags, and it's simply > not feasible to transform our SHA256 hashes (of the NAR-encoded source > checkout) into something that we can use to fetch the archived source > from SWH.  There's simply no hope to make that work, unless we can > convince SWH to maintain a secondary index of their content based on > NAR-encoded source trees, which seems unlikely. As pointed out elsewhere, SWH keeps a history of the tags that we could look up until one matches, and there'd also be the option to keep a secondary index ourselves (or have a third party do it). > On the other hand, if we refer to git _commit hashes_, then it *is* > feasible for us to fetch the archived source from SWH, regardless of > what upstream has done to its tags in the meantime. > > For that reason alone, I think that the way Ricardo wrote the > guile-aiscm package definition is clearly the right approach, given > Guix's longstanding goals. To me, it rather sounds like a workaround for longstanding bugs [1, 2]. And then again it rests on the assumption that upstream does awful things to their tags which makes no sense when it makes sense. > > On the note of fallbacks, we do also have the issue that Guix fails > > on the first download that does not match the hash instead of e.g. > > continuing to SWH to fetch an archive of the old tag (as well as > > other fallback-related issues, also including the "Tricking Peer > > Review" thread). > > That's a bug that can, and should, be fixed.  The existence of that > bug might temporarily prevent us from enjoying the benefits of > Ricardo's approach, but that's not an argument for adopting practices > that push us farther from our core goals. > > What do you think? Which bug are you talking about? "Tricking Peer Review" or the fallback thing? If it's the fallback thing, then that's an enabler for Ricardo's approach, since as you pointed out the commit will still be fetched correctly from SWH (if not from the main repo itself). Insufficient fallbacks are what make it painful to refer to moving commit tags by tag, since our SWH lookup currently breaks when it doesn't need to. Having sufficient fallbacks would mean that we could use git tags as we did before even in those cases, since the SWH (or other) fallback would kick in and give us the historical version matching our origin-hash. Now, "Tricking Peer Review" is a harder thing to circumvent. We would need to issue a warning, preferably a big one if fallbacks do kick in unintended, i.e. particularly outside of time-machine. Cheers [1] https://issues.guix.gnu.org/28659 [2] https://issues.guix.gnu.org/39575