From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id GCKANs4fz2HGLAAAgWs5BA (envelope-from ) for ; Fri, 31 Dec 2021 16:20:46 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id cN4PM84fz2FSvAAAauVa8A (envelope-from ) for ; Fri, 31 Dec 2021 16:20:46 +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 401253744F for ; Fri, 31 Dec 2021 16:20:46 +0100 (CET) Received: from localhost ([::1]:44656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3Ji0-0005dj-Ly for larch@yhetil.org; Fri, 31 Dec 2021 10:20:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:60694) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3JhI-0005dZ-Oh for guix-devel@gnu.org; Fri, 31 Dec 2021 10:20:00 -0500 Received: from [2a00:1450:4864:20::444] (port=40803 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 1n3JhG-0004M6-M8 for guix-devel@gnu.org; Fri, 31 Dec 2021 10:20:00 -0500 Received: by mail-wr1-x444.google.com with SMTP id q16so56498480wrg.7 for ; Fri, 31 Dec 2021 07:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:subject:from:to:cc:date:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=vl16ZR0kNmhgkYYXpA6XTC7KmoqLguxEIdzmcnvFQPY=; b=WJ1jVzhqCIUaXT/wZbcMzIz6xJn1BROHav/Ig2XL81V+4W4aec+p378oanBmF6M3uX rnNK6YhMBryYKbwsjBfgPqC6Ghdrxt/52m5n95fnRxx3vDFc/VHyd+SvcMrvAWLc/NqT ngkmEd2Lo9zA7RlmefNcgqZjkiK1jY5kL3p5NgTd7QogdCpO0hO+e5JBUxWgp9330qvX 1SZsezD24a5BZS843ViA8eR+WMPA69/Qq/0b9JV61uqUYNVGaSKndEGNV1nCMHTQUjuq mnH6wtC4ldypZBygtFj//sLIYXS8TJMv+hSQUZdYWjnEqXfMloB1iDV0E3xeHEBbIbfk Qudw== 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:cc:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=vl16ZR0kNmhgkYYXpA6XTC7KmoqLguxEIdzmcnvFQPY=; b=2YAqdvUlyBT/Jd2d0ThTqyHJ2yUqHbKmc3re5x5j5/LW9nQDnuzCA/TCl7iXdrZqO1 KCFuMyOVlL0En+ou4xLLTQKGI6JKAYvHyvrFn8Q2Sr+q3BQTxHCQFa475hjzt1B9lV8W JTJuVCQUK0N9/Qq8O83KW6+7LFDyTws6DIWb/rpOXbW3CZfnayreI6uDezsjm2jy8b6x ShdWmg3UYyZMGePlhkW82Mtt4XZ3YEWN88un6jvz/DDElFtuWXBs153DnEsPBrG5Fff2 vrTWuPGgD1H0TONW91XRpKHhziLFG5FbKkS+LwXKbff+vIJj3XIPqZ4bd37oR5+LstxE OXCw== X-Gm-Message-State: AOAM530Xl/xApTbbOiwCYvgkWdeKbTAH/O2iuBVSyB2bCSUJWT7vlNWi ASP5YbiU3OTzZ2Ok50oUWzA= X-Google-Smtp-Source: ABdhPJzyklkrBzNjRsDQPknSWcS0Z5hgl52AlFS1gGabBw/7muZKJW7zBWv6EqoKj1Q7ii5lEQ5Zqw== X-Received: by 2002:adf:d1e2:: with SMTP id g2mr29236758wrd.346.1640963996884; Fri, 31 Dec 2021 07:19:56 -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 w21sm22393805wmi.19.2021.12.31.07.19.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Dec 2021 07:19:56 -0800 (PST) Message-ID: Subject: Re: On raw strings in commit field From: Liliana Marie Prikler To: zimoun , Ricardo Wurmus Date: Fri, 31 Dec 2021 16:19:55 +0100 In-Reply-To: <86ilv46hls.fsf@gmail.com> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <86y243kdoo.fsf@gmail.com> <899587fb6a76ddfa37d197d3d0fd23cdc7ad8592.camel@gmail.com> <867dbmi7pf.fsf@gmail.com> <3d448fe42f0c43574db96fa26aecd7da5fd5a95d.camel@gmail.com> <86k0flpnx5.fsf@gmail.com> <9a5e3e7f44155146d731dd5a97450a9ff9dff5ab.camel@gmail.com> <87bl0xglul.fsf@elephly.net> <86ilv46hls.fsf@gmail.com> 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: , Cc: guix-devel@gnu.org 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=1640964046; 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=vl16ZR0kNmhgkYYXpA6XTC7KmoqLguxEIdzmcnvFQPY=; b=YsX0+rV8+Q8FyUhClzG2SBMCBIW5ZzTtDHw0gMiGBXYszZ+6DILv61D4YYbPI6/xbxsxeY UaKFF4PC9wffw7YUlrrFVYm3Yq2nwxw/vnJtD3H19bnKAfmcUFCanobFME4IUBx6p6fjgX ktdcBV4QJe1P/Z9W3ktrdSeS7JcgWOQPpyrONA/lCHLXlLl0byoi59TH9hSu+TmSlNzlmR w+CdI1iHspk07/SgArzVUN9FKwLt+pAYwuQaBe3bsIrSuk5yuM4dfViIj5cmknBWEAovPO GOaMCLLn6bGxW/4DEL2WLKma+pYm1vQAE41tHLKkqLxSMQ0WvQg1iYPbCwLSEw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640964046; a=rsa-sha256; cv=none; b=haDpZZQhGva7pimTtZJJKdkv/yqkME5W6ZaLkv7/hCMR9QTwNGt0+dKU55yA+bCeLfOVxi lJMKaLPWJVf2MkRrJcfgalYL4t0RxfxufIFbu1CGK8CiEo55QFizu4dPkTpazouB1CE3uz uTFrXC2u8oW1+uQkK6vRp1RNBa47jr1nonSu63EEOS9aVTpgmI2ip7oxjraUG6UFpOAg3V d7UtFKueQC8ZXFelDNquya3dqQH18jNa5iFUnooopwWBx/62yob1JkM7Yx4EXLkLQ0eBWF h1OHB15mA7hafksQ6TrEbCNR7PG+Jtg2OJefQ3uWXCtCd9q3YuCOGrfpiaGCiw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WJ1jVzhq; 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: -6.58 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=WJ1jVzhq; 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: 401253744F X-Spam-Score: -6.58 X-Migadu-Scanner: scn0.migadu.com X-TUID: 5BqNMC68BvjE Hi, Am Freitag, dem 31.12.2021 um 14:15 +0100 schrieb zimoun: > [...] > Version is also Guix specific.  Sometimes, we patch; for security > reasons, for fixing a bug, for quickly backporting something, for > removing non-free bits, for unbundling stuff, for making work with > the rest of Guix packages or for whatever other reasons – or we apply > some options for building specifically for Guix.  Then, the version > “1.2.3” is not always changed and therefore it does not necessary > correspond to what upstream refers as “1.2.3”, or what Debian calls > “1.2.3”, etc. I think this is generally what you expect from a distro. From my personal experience with Debian-based distros and Gentoo, they do sometimes need to use revisions for when they update their own patches, but we do have the upper hand here with `guix describe'. > [...] > > On a side note, I miss why using commit hash is an issue for ’git- > fetch’ – despite the fact of content-address advantages – when it > seems not for ’svn-fetch’ as in: > > --8<---------------cut here---------------start------------->8--- >     (version "0.5.1") >     (source >      (origin >        (method svn-fetch) >        (uri (svn-reference >              (url (string-append >                    "https://code.call-cc.org/svn/chicken-eggs/" >                    "release/5/srfi-1/tags/" >                    version)) >              (revision 39055) >              (user-name "anonymous") >              (password ""))) >        (file-name (string-append "chicken-srfi-1" version "- > checkout")) >        (sha256 >         (base32 >          "02940zsjrmn7c34rnp1rllm2nahh9jvszlzrw8ak4pf31q09cmq1")))) > --8<---------------cut here---------------end--------------->8--- > > or other example > > --8<---------------cut here---------------start------------->8--- >   (let ((revision 505) >         (release "1.09.01")) >     (package >       (name "fullswof-2d") >       (version release) >       (source (origin >                (method svn-fetch) >                (uri (svn-reference >                      (url (string-append > "https://subversion.renater.fr/" >                                          "anonscm/svn/fullswof- > 2d/tags/" >                                          "release-" version)) >                      (revision revision))) >                (file-name (string-append "fullswof-2d-" version "- > checkout")) >                (sha256 >                 (base32 >                  > "16v08dx7h7n4wyddzbwimazwyj74ynis12mpjfkay4243npy44b8")))) > --8<---------------cut here---------------end--------------->8--- > > I let aside the readability point for git-fetch or any others since > it is only habits or more precisely collective conventions and a bit > of personal preferences. :-). I don't think the SVN comparison here is fair. For one, the examples reference the tagged revision doubly -- once by revision, once by tag. We don't have a way of doing that for git (currently). Plus, an SVN revision does have more intrinsic meaning than a git hash. > When we speak about robustness and long-term, the issue is the field > ’uri’.  Having something extrinsic, i.e., which does not depend on > the content, as URL+tag or URL+revision or just URL leads to fragile > fetching methods depending on the Moon phase. > > What Disarchive is currently doing for url-fetch is somehow to index > by integrity field, depending only on the content itself (sha256; > usually not using nix-base32 format referred as ’base32’ in ’origin’ > but instead ’base16’ format, whatever).  In short and quickly said, > Disarchive-DB does 2 things more or less, first it somehow maps from > this integrity hash to swhid hash allowing to lookup in SWH archive > and fetches the data, and second it stores metadata, indexed by > integrity field, allowing to reassemble the content = data + > metadata. > > We were discussing to do this strategy for all the fetching methods. > And potentially add more than swhid hash as content-address systems; > somehow. You're also missing the part in which it currently relies on a single server to do all this, but there are plans to move it out to multiple ones, i.e. adding fallbacks/redundancy to your fallback mechanism, which for the record is a good idea to have. > All the robustness now relies on the availability of the Disarchive > service.  Based on this context, what I miss in all the discussion is > that Git owns a built-in solution (commit hash) and the arguments for > not using it appears to me weak considering the easy advantage it > brings. > > It is a difficult topic to know what information the ’uri’ field > should contain for robust long-term; a topic with a lot of unknowns, > although many solutions are around, they are a strong change of > habits and changing my own habits is already hard, so a collective > change is a big collective challenge. :-) We're going back to Cantor's argument for raw commits. I'm not opposed to using commits as value of the commit field (let-bound commits reflected in the version, that is), but let's not forget that this robustness argument still presupposes that the (commit tag) binding is the point of failure. This probably holds to some degree for "npm- something", but we also have a fair amount of e.g. GNOME-related packages which we trust to have robust tags and the only reason we don't use mirror://gnome to refer to them is because it's not in GNOME mirrors (yet). > For instance, SWH promotes swhid instead of DOI for referencing the > publications.  I am not sure it is really popular outside a small > French subgroup. ;-) Completely off-topic, but isn't part of the point of DOIs that you can fetch the revised paper as well? I can understand putting OpenData behind an SWH ID rather than a DOI, but the paper itself? Why? > Somehow, find some rationale –readability, matching versions, etc.– > and then find counter-measures of their flaws to keep extrinsic > values –tag, revision, etc.– is, for what my opinion is worth, not > the correct level or frame when thinking about robustness and long- > term. For what it's worth, I don't think content addressing everything (particularly relying on a single service to do so) is robust in the long term, it just introduces larger failure points. The only robust way of increasing robustness is to add more fallbacks and redundancies (and actually use them). Cheers