From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.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 INrVJaADz2HoAgEAgWs5BA (envelope-from ) for ; Fri, 31 Dec 2021 14:20:32 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4HEII6ADz2GvZgEA9RJhRA (envelope-from ) for ; Fri, 31 Dec 2021 14:20:32 +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 E9EDF3284D for ; Fri, 31 Dec 2021 14:20:31 +0100 (CET) Received: from localhost ([::1]:60796 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3Hpf-0004qC-3A for larch@yhetil.org; Fri, 31 Dec 2021 08:20:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59740) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3HoT-0004ny-PT for guix-devel@gnu.org; Fri, 31 Dec 2021 08:19:18 -0500 Received: from [2a00:1450:4864:20::433] (port=44986 helo=mail-wr1-x433.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n3HoR-0004Db-Rm for guix-devel@gnu.org; Fri, 31 Dec 2021 08:19:17 -0500 Received: by mail-wr1-x433.google.com with SMTP id k18so19239324wrg.11 for ; Fri, 31 Dec 2021 05:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version:content-transfer-encoding; bh=0lJJXXpYyO215p+iTKBIS3ehpM3NsjCTPbjle9FWdYI=; b=B9sqnKJTLkgOGBXwxnPoXxXXsEC/3ualgq+ghdIiEP0WNQFuKz35MDW07WV68jEawr nIPcsMUBJTrnppQnsxykk7NER1JkJvkR86GKzdvdlm4R55ggF9I5+VvroSCEd4uCo2Nv 76BnTQktyTOSbXhbv7UOaYuY23xkdMYLznRea+nSqaIOmHjIStdEzIdd39TorahtBLLO YfldGBZnNWeM/F+4Jgyt8M175WAaBj5gVbRpOw9fa3p/e8NQq3LHp9hIEp+2FPnI+70T zK8fUwy2gs+Ndqa3XuEsztM6jeBDAlYu3W7zN+3bHUVTxg8FKz1klkbnMTumAPacRTuA BaVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version:content-transfer-encoding; bh=0lJJXXpYyO215p+iTKBIS3ehpM3NsjCTPbjle9FWdYI=; b=5zsc2Vo1tzbxZ6vXU69TgMfyf/HXfG4Fi21XuoPUVvgsNXv0RRUpa+cAkyztiSu/vl IjW2RNZ/8KbMBIoAQTihAfJp8XkPL9IHGaeMAC57rdcvBGJEhMo3xZe62PV1eEi5DJOy 60G9BRSD50kOmGGN+Bn9pr/GCBxqQEg8M1hf7P3WusGbseW4f34TWrDOVoK7HO22c51e 2A/7+70L9xSEC1KMcDC6F/fqjzhSWKfSKqEV47E2C9oEcWMvjjosedgHEV81nagX6Hbs L2W8Rj5x5YzFW3xJ44E6nro+8AuhRH2Z+d906QIIaptyIVS8I6i1WeO6ifTxkFaAmJK9 ORlw== X-Gm-Message-State: AOAM530Iezry0uS55Rj2QE9rxwJC6PvIIR8Z8YXnYoq64WTLAxsjHxNf /AZZQ2sEQy4pKgiS5GWiF9av7Tu1q2d0mw== X-Google-Smtp-Source: ABdhPJzEhazlpltQcUsHKj1TBzZFhy7gpFNRkGGhfWVvr2+0Bt7662L8QwMbmCrvshiW+cVT6N/q8A== X-Received: by 2002:a5d:660e:: with SMTP id n14mr29201925wru.613.1640956753869; Fri, 31 Dec 2021 05:19:13 -0800 (PST) Received: from lili (2a01cb04061b8800e2568b9190e03e61.ipv6.abo.wanadoo.fr. [2a01:cb04:61b:8800:e256:8b91:90e0:3e61]) by smtp.gmail.com with ESMTPSA id i8sm27164101wmq.4.2021.12.31.05.19.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Dec 2021 05:19:13 -0800 (PST) From: zimoun To: Ricardo Wurmus , Liliana Marie Prikler Subject: Re: On raw strings in commit field In-Reply-To: <87bl0xglul.fsf@elephly.net> 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> Date: Fri, 31 Dec 2021 14:15:11 +0100 Message-ID: <86ilv46hls.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::433 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::433; envelope-from=zimon.toutoune@gmail.com; helo=mail-wr1-x433.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=1640956832; 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=0lJJXXpYyO215p+iTKBIS3ehpM3NsjCTPbjle9FWdYI=; b=QS1LqfyFRPHMgkfdJhek5QOaQj94ZwOn8dxAmOvMQ6VgkFLwWPfLZIbpL3fuBA1y9Jfvi4 mWUKhFWKHSqV/c9MTVTSiqePr4iiN4OLKPLxCnBbWweW0OdqS/GDPNGbRQxrVdVoQ/x8hk U2/yhF+xdbJGMSP+0lY11/HMBqmZ4xJdZwd6JgkhGxUywszQPjRCcCLGyZppgCzUzZcWPJ /2fycYdtQtz5pHopS84wAnx3G475MeOkXfhh3UB2pStdkX4y89hyMDZcEQDoAh/KihUxGn qpoceZrB8nwH98/VP4kxO/o8ZAJlFPGl9yJzVafaBFcUI//3grKFa6FyGyECLQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640956832; a=rsa-sha256; cv=none; b=mDhyqtThm/jGBAVXsLi2ctaUvXpJPVXeq4mWx+uqTK5wdKYN0kd/XPLOfCHy2Rw4BE1zEk 6jb+fNL9C2QTAQxN5CzF5Jxz5oXxq6efBiBdNGUknpwk9EhLrhobiRr/qFecW6QDRJEhNQ dZFZDzNrmgOnv+NJ0tnjhc8rlP4cmXryQPWYnG3O9bRV7RCQCKfncCtUYhX3UwLH1GjEuP k/qEZElItXNH1T7EWUT3SHtSmM3nR+abFwjnZfAOxO8XentM5l2+6x+sWRAR7MScFtGqJr XPbTODaEwo/tzlVr7vgutO2QwXtUd3nZgebecxcD8JHAXf/71On2nhu6xu1Kbg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=B9sqnKJT; 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=B9sqnKJT; 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: E9EDF3284D X-Spam-Score: -4.28 X-Migadu-Scanner: scn1.migadu.com X-TUID: EdBwHQKwDcnx Hi all, On Fri, 31 Dec 2021 at 10:31, Ricardo Wurmus wrote: > I have no strong feelings for or against any of the proposed options. I > think that using raw commits might not be great for our tooling because > we=E2=80=99re not reusing an existing version string and would need to re= member > to update the raw commit as well. But other than that I don=E2=80=99t fi= nd the > raw commit to introduce readability problems for humans. By tooling, Ricardo, do you mean the =E2=80=99importers=E2=80=99 and other = =E2=80=99updaters=E2=80=99? Well, a general minor comment about readability and metadata. The anatomy of a package is: --8<---------------cut here---------------start------------->8--- (define-public a-symbol (package (name "a-name") (version "1.2.3") (source (origin (method git-fetch) (uri (git-reference (url "https://an-url.somewhere") (commit ????))) (file-name (git-file-name name version)) (sha256 (base32 "09rdbcr8dinzijyx9h940ann91yjlbg0fangx365llhvy354n840")))) (build-system gnu-build-system) (home-page "https://another-url.somewhere) (synopsis "Guile extension for numerical arrays and tensors") (description "AIscm is a Guile extension for numerical arrays and tenso= rs. Performance is achieved by using the LLVM JIT compiler.") (license license:gpl3+))) --8<---------------cut here---------------end--------------->8--- and here, a-symbol, a-name and various home-page, synopsis, description are Guix specific. They are metadata added by Guix packagers. 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 =E2=80=93 or we apply s= ome options for building specifically for Guix. Then, the version =E2=80=9C1.2= .3=E2=80=9D is not always changed and therefore it does not necessary correspond to what upstream refers as =E2=80=9C1.2.3=E2=80=9D, or what Debian calls =E2= =80=9C1.2.3=E2=80=9D, etc. The field =E2=80=99version=E2=80=99 is Guix specific, at the same level of = metadata as =E2=80=99name=E2=80=99, =E2=80=99home-page=E2=80=99, =E2=80=99synopsis=E2= =80=99 or =E2=80=99description=E2=80=99. Other said, these fields only depend on choices made by the Guix packagers. Then, the =E2=80=99origin=E2=80=99 part is not Guix specific. It is only u= pstream specific. Obviously, as packages distributor, the Guix specific =E2=80=99version=E2= =80=99 matches as much as possible with what upstream refers as their version, most of the time using the Git feature of tag. This tag is upstream specific: sometimes is =E2=80=9Cv1.2.3=E2=80=9D, sometimes =E2=80=9C1.2.3=E2=80=9D, s= ometimes =E2=80=9Crelease-1.2.3=E2=80=9D, sometimes =E2=80=9Cr1.2.3=E2=80=9D, or whatever else. We often map =E2=80= =99version=E2=80=99 to =E2=80=99tag=E2=80=99 using =E2=80=99string-append=E2=80=99. For other methods that git-fetch, we also use a map, but instead, from =E2=80=99version=E2=80=99 to URL, or from =E2=80=99version=E2=80=99 to =E2= =80=99changeset=E2=80=99, or from =E2=80=99version=E2=80=99 to =E2=80=99revision=E2=80=99, etc. On a side note, I miss why using commit hash is an issue for =E2=80=99git-f= etch=E2=80=99 =E2=80=93 despite the fact of content-address advantages =E2=80=93 when it = seems not for =E2=80=99svn-fetch=E2=80=99 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. :-). When we speak about robustness and long-term, the issue is the field =E2=80=99uri=E2=80=99. Having something extrinsic, i.e., which does not de= pend 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 =E2=80=99base32=E2=80=99 in =E2=80= =99origin=E2=80=99 but instead =E2=80=99base16=E2=80=99 format, whatever). In short and quickly said, Dis= archive-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 =3D 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. 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 =E2=80=99uri=E2=80=99 = 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. :-) 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. ;-) Somehow, find some rationale =E2=80=93readability, matching versions, etc.= =E2=80=93 and then find counter-measures of their flaws to keep extrinsic values =E2=80= =93tag, revision, etc.=E2=80=93 is, for what my opinion is worth, not the correct l= evel or frame when thinking about robustness and long-term. Cheers, simon