From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:306:f42::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id aDihHdp5y2FNPQAAgWs5BA (envelope-from ) for ; Tue, 28 Dec 2021 21:55:54 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id YEGPGtp5y2H3XAAAauVa8A (envelope-from ) for ; Tue, 28 Dec 2021 21:55:54 +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 ECA55684 for ; Tue, 28 Dec 2021 21:55:53 +0100 (CET) Received: from localhost ([::1]:48718 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n2JVg-0006PL-Lb for larch@yhetil.org; Tue, 28 Dec 2021 15:55:52 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35356) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n2JVK-0006Of-Hy for guix-devel@gnu.org; Tue, 28 Dec 2021 15:55:30 -0500 Received: from [2a00:1450:4864:20::442] (port=35570 helo=mail-wr1-x442.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n2JVI-0006MY-FH for guix-devel@gnu.org; Tue, 28 Dec 2021 15:55:30 -0500 Received: by mail-wr1-x442.google.com with SMTP id j18so40498011wrd.2 for ; Tue, 28 Dec 2021 12:55:24 -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:user-agent:mime-version :content-transfer-encoding; bh=z++6sWebIPFbday2MBhylB5BS5D//uT/ZqGxQ+w/1Qg=; b=NqPjxh5+AgYjhcCvlI0QfGRIVOUkDZHa79zWzHCqOMMLBghXMtGHL/U0T0lLyD3Oo5 dyX+YT6iUSCnSUG8ovAQFRtlXA7X68ElzFDZN8aOLQlVS0K4YXKg3YpyknZV8S1o1qMS zc4CpcRENnmvsTLwHOFNWnCmuE7Qbz2zJI1xA88f7pvKumvGWxncWREe6T6iaulcaFDK 4MckjyTYbNl5ia5b68AK6uAr1s9vWnrI1dxWXvA1iIbALb8/UYoawW0m6QDK6m4/q+Lx YxImWCAkSl6ClCk4DcW28YeLvm+Yj3gQm4WLWn3h06/1lWGRlO6eG+tnDCrhZr2FJklr nQ6Q== 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:user-agent :mime-version:content-transfer-encoding; bh=z++6sWebIPFbday2MBhylB5BS5D//uT/ZqGxQ+w/1Qg=; b=Sc/YAS/jGIEIpJYOzUuIMQSQsCU7UHaPS6YolrP6suxs6FZSj0uUvUe+5BmgTB6s6W kGICiUKiOwt+dMS4qJ7vT0tq5K07HiJxugtG+AC43IZrboTnMMbb0IzDvA1Q41aRXSO9 XYY5HwE18SVj87MGe/EgfcFMlgEMhDOUkqj+jAPFuz72kWGD4Kw+a4E86v2n9NLmWJwq 5YPuME/oPdGTNGz+ljnAdB/Av5HWkaQkG2KGDJK7eDYii3tGVZYLR+CY3BLKqTumSOnz NCAdxNulOg5d9/uXBQZLVPXWXSNbRtwCcpy0JXmVJtKvD4mF0WxOQbwzdtf1MDvE01qd HOTA== X-Gm-Message-State: AOAM533ViAT/AthI+dbPLHdkxI6bZWZyJwUCZuUUnOkS0+IkWM9h1wyL XPnDPbcIFBgOvm/mbwMMghsHZV4U59gFXw== X-Google-Smtp-Source: ABdhPJw/lMZFKJHQdpRMn+T5FEzYFUjK+sZ8kZ+DDp3EEkX4D7tYRZBjDsfzlltQlCUJo0U/tEUUyg== X-Received: by 2002:a5d:4690:: with SMTP id u16mr18588368wrq.321.1640724923513; Tue, 28 Dec 2021 12:55:23 -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 v1sm21797869wru.45.2021.12.28.12.55.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Dec 2021 12:55:23 -0800 (PST) Message-ID: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> Subject: On raw strings in commit field From: Liliana Marie Prikler To: guix-devel@gnu.org Date: Tue, 28 Dec 2021 21:55:21 +0100 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::442 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::442; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x442.google.com X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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_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=1640724954; 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:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=z++6sWebIPFbday2MBhylB5BS5D//uT/ZqGxQ+w/1Qg=; b=to7jGXfMxQigcFjDovyIraUCZOA6zYCXM3eHpkb4mhMlLMp5W859O24BKIAU87swK7luoL x8I1EZlJmYcDRAGkCgEOU4Jh18a1FAX/LMu82Uvrsu/gW7Lc99yb05tngpXRvMhL2cZR57 rusaXKtXbExt0bSx2CtjPLPJeMVzoXESuExrv9GW8dAYidCSFw5WicyNyY22m5PWs/otbz amot1Mcy9v7ziKDCzacgB5wrShG9upOgwkr9EnZxlRj1Vm8s3FCIagBRGiEQWYoeydzMAF /2Queum1YcK223/h0HhRbvzsNes6AEdj7Hsajsvc2CJ3y25/f7Dp/GBVlFx4Ig== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640724954; a=rsa-sha256; cv=none; b=KlHMJbD4rhhgHPz+/pjeYnw+DRr1fitN57uWs4DcpT3Ih85j3U17ToDtETXvkoMpCIh6nR HWN2sjsJgsQWXRyiWRrnqAjR0ekSbpi6UOgkNuiFOdvw16mSg/PjN5gqLnRaPrYbzat+x7 ERdazD9pcn1EI8KlPFol4btcFdY2zXjIvClZ7AZMw/XR3DfJGVhLDW7ZhjH+wiyyGKkZqL CeIFZwNizO8aEyZYNh9z97uAqxk3+8VxCWsnpeMbyZX19N6FgQgNLryW8gc0Dr2KoeBHkT O/RYOS46rmeuHjgGf3yZFhzH7DwatDwh7XK4hRn7NYZwPt/5tnEfZIcI/SyqNg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=NqPjxh5+; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: -1.97 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20210112 header.b=NqPjxh5+; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); 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: ECA55684 X-Spam-Score: -1.97 X-Migadu-Scanner: scn1.migadu.com X-TUID: ra8qGhfBAIFL Hi Guix, when Ricardo recently added guile-aiscm to Guix, I was confused that both the version field of the package and the commit field of the git- reference used in its origin. It turns out, that this is a rare pattern observed in less than 200 packages currently in Guix. The reason to do so (as far as I understand and was explained to me in IRC) is that commit tags are in principle mutable and hence can not be relied on when fetching sources. I do have a few issues with that explanation, but before that let's go a step back and discuss the relation of version and commit. Consider a package being added or updated in Guix. At the time of commit, we have the tag v1.2.3 pointing towards commit deadbeef. We therefore create a guix package with version "1.2.3" pointing to said commit (either directly or indirectly). At this point, one of the following holds: (1) Guix "1.2.3" -> upstream "v1.2.3" -> upstream "deadbeef" (2) Guix "1.2.3" -> upstream "deadbeef" <- upstream "v1.2.3" >From either, we can follow that Guix "1.2.3" = upstream "v1.2.3". If upstream keeps their tags around, then both forms are equivalent, but (1) is more convenient; it allows us to derive commit from version, which is often done through an affine mapping. Problems arise, when upstreams move or delete tags. At this point, guix packages that use them break and are no longer able to fetch their source code. Raw commits are in principle resilient to this kind of denial of service; instead upstreams would have to actually delete the commits themselves, including also possible backups such as SWH to break it. There is certainly an argument for robustness to be made here, particularly concerning `guix time-machine', though as noted it is not infallible.   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. Widespread use of this pattern under the above reasoning would imply that those upstreams can't be trusted to have stable tags when there are probably few offenders in that category (considering also that Guix is not the only tool they'd break if they do move or delete tags). More importantly, if we do have a non-trustworthy upstream, it could be reasoned that referring to some tag is as good as referring to a random commit and thereby let-bound commits and revisions ought to be used. As any good Sith would, the above talks in absolutes, or at the very least uses default logic without considerable fallbacks. 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). Putting those aside for a while, there is an all but endless amount of upstreams for which we can't tell ahead of time whether they will act nicely or not. The status quo for most of our packages is to assume that they do and fail loudly if they don't. The proposed alternative is to assume they don't and miss out on nice things if they do. However, even under that assumption we also miss out on ninja version bumps and the only way of noticing other than paranoid amounts of checking whether the tag moved would be to wait for a mail from upstream claiming that they actually wanted us to notice the ninja bump. Neither of the above is really satisfactory. At the very least, if raw strings are to be used in the commit fields for tags that "once existed, but maybe no longer point to that commit", I'd want a comment like the ones I find in minetest.scm to mentally prepare me for what I'm about to read in the rest of the package description, but I'd much prefer using let-bound commit/revision pairs. Perhaps we could make revision "0" (alternatively #f if we don't want current versions to break) special in that a git-version with it expands to just version.   Long-term, we might want to support having multiple in git-fetch -- if the first one fails due to a hash mismatch, we would warn about that instead of producing an error and thereafter continue with the second, third, etc. similar to how we currently have mirror:// urls for some well-known mirrored repositories. That way, we have a system to warn us about naughty upstreams while also providing robustness for the time machine. What do y'all think?