From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.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 8BRVBbLhzmGbHwAAgWs5BA (envelope-from ) for ; Fri, 31 Dec 2021 11:55:46 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 6GOOObHhzmFrSQEAG6o9tA (envelope-from ) for ; Fri, 31 Dec 2021 11:55:45 +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 7573216F51 for ; Fri, 31 Dec 2021 11:55:45 +0100 (CET) Received: from localhost ([::1]:59698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n3FZY-0000AJ-LN for larch@yhetil.org; Fri, 31 Dec 2021 05:55:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52830) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n3FZ2-0000A1-KS for guix-devel@gnu.org; Fri, 31 Dec 2021 05:55:12 -0500 Received: from [2a00:1450:4864:20::441] (port=33701 helo=mail-wr1-x441.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n3FZ0-0004JV-UU for guix-devel@gnu.org; Fri, 31 Dec 2021 05:55:12 -0500 Received: by mail-wr1-x441.google.com with SMTP id d9so55478537wrb.0 for ; Fri, 31 Dec 2021 02:55:10 -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=Wh1EmnjHI5gKa9ReIE/agTF4qaCuXfUKbdW2LHAkziU=; b=Ncltk9HleJJ6Jo9thFUH2XUCcuq2tkcvrZ0DtSSv7jr62y16wMv6/FT2oS8SHOnLvP PZBU53lq/KufzEM8n9toQKd8bASCRt0iwPPntL1gdaboJvXIiAgz8IWA+aDAtEKIlBtM y8gliLrL3ZuJpv/cMM/ZbRb4qOW+I/Shy18jjOSHdw2bzNBTWNVd2HS+UY3r/5DizOFi NkAJRvCfdclBfinJr8PvQWfvYm+2iYXkqd26CNbKzLxQgno9aFDbpEoGWiYHmfTJhfbN Y9miYamXIqIv9qpwzSt0urruMNbPrJzZ5M3TPNDBJ59x8O+WynRr/tfT/tKFnkQag4SV Lahg== 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=Wh1EmnjHI5gKa9ReIE/agTF4qaCuXfUKbdW2LHAkziU=; b=bpffRIwQTG+YdbV6rEL+tTnkw7/zIhqFCR+daKuic5gABj3TQ2TCvJ6PoyzH0HfGLy ppFulxCka0oRQlVStgS4rgJ/bSq80HvNt3QxfFHDiYNOV21daKLaoNFrAD7dgJJksR+B lRwtg5vTgTVPTlv0lezgLbmfpOpmHH/6U+A9dIsVzAE8BnlASwj7+p1AI7G8LT48kSYJ R32etUBsE6y04RJymcJNFaT02IdaTEXo2gHHSel4S8hhDn0mqj5gnhUtDwKnDLf8jjx5 kmIeGLKvsfuz/okANLMBMOKN4ldsa318R7obbbbVROxe0y9pXA5+OOG7BuwoI9lSmUUZ UKPw== X-Gm-Message-State: AOAM530x4AToeVzRFYblkhpSgC+UZcwGmfpDww4l2BnUWhA7w77vNgCP Recq+0TF8XKGA8LUru9OXLT8raytFF4RPQ== X-Google-Smtp-Source: ABdhPJy1GrkyutaBVCbI+72b3OP0pvbokg5BO5mHZgr2Wojsgz4UYr7Oc3/Rd1ENQoord11/qW29Lw== X-Received: by 2002:a5d:4690:: with SMTP id u16mr29937631wrq.321.1640948109511; Fri, 31 Dec 2021 02:55:09 -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 l4sm26273481wrm.62.2021.12.31.02.55.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 31 Dec 2021 02:55:09 -0800 (PST) Message-ID: <696347efa3a0ac449f538ef8bf2f6e42a517c5e0.camel@gmail.com> Subject: Re: On raw strings in commit field From: Liliana Marie Prikler To: Taylan Kammer , Mark H Weaver , guix-devel@gnu.org Date: Fri, 31 Dec 2021 11:55:07 +0100 In-Reply-To: <97f31fd3-38bd-1744-bb03-6ae514ae78a9@gmail.com> References: <6e451a878b749d4afb6eede9b476e5faabb0d609.camel@gmail.com> <87k0fm7v3k.fsf@netris.org> <97f31fd3-38bd-1744-bb03-6ae514ae78a9@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::441 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::441; envelope-from=liliana.prikler@gmail.com; helo=mail-wr1-x441.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=1640948145; 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=Wh1EmnjHI5gKa9ReIE/agTF4qaCuXfUKbdW2LHAkziU=; b=oSC6bxZzHsBAh3GYTFboi5wBdUTCp6HwaIAzArDwUy50bS5WaVZu/sixSB+h35t7guzbP2 EbKgM3r18BrWyaVicwokbZuig3DD7n9Iy8lYL60gVeSvQXgKNjzz6k3hmxOCeoNJGdYb26 J3cilQWugymb1mjvJ3WnzoJzhQ7d1lUWfqLizzMfrjjjxXxbcMGvm+zCoI1RIbDCJplcEL pKFrfkCNSaViAwlTHSDBv8tkwQWOv84jwbnbwT5DOjeu3sZuqokZMHRh39+dm00k5HqoZm 9w0bSrIC75JJWAErFQrzRJceKQPiw2LCF5tRbDqPHlENb3ecSXcANxadvsrlPw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1640948145; a=rsa-sha256; cv=none; b=kCmjshtwOeY21pyKxoYU2GOrZs6rlxpZKu2CYkJMpqfEJ+l3qdVVn0FrdssWnTtO0p808B ViHfczuh8BNC6+j6xdbyITwnSSQAA+ClPHJZgg8W7wUStKpttxBLNBZE+/TNqd7yjJ0ELz U1v4+wuXDcb9zhzCQLIql9kPicJJGDFj8vfuDfGBMC6rcA30ZG7OSyuxzwRgYn9o5bPV3c GBtWMKTYIkdaSDJz1i4462j/Mz6AO4oifjycFTuw9/fBANrHvLUfdqUV2AWky4tLkP57LT 3vnPgeEujmBB/d3DiG42rqq3QMYFB0D15F5GOkrkWUjMB6wdz+LlPdYKzWySQA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ncltk9Hl; 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=Ncltk9Hl; 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: 7573216F51 X-Spam-Score: -4.28 X-Migadu-Scanner: scn1.migadu.com X-TUID: hMtQXODNd7aH Hi, Am Freitag, dem 31.12.2021 um 08:57 +0100 schrieb Taylan Kammer: > On 31.12.2021 04:15, Liliana Marie Prikler wrote: > >                                                   [...] 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". [...] > > I think here lies the crux of the disagreement.  As far as I > understand, Guix doesn't intend to support the notion that one > version string could represent two different actual versions of a > program throughout time. It does not [intend ...], but the failure mode is important here, particularly also for outside observers. An outside observer seeing that Guix uses commit deadbeef for "1.2.3" whereas upstream has bedeadaf for the same might not know that upstream moved their commit and given that committers can do much without oversight, they could also sneak in a malicious deadbeef when upstream "1.2.3" was actually d000000d all along. If Ricardo had pushed to staging or core-updates, that commit could have gone unnoticed for far longer (and just to be sure, I do trust Ricardo to pick the right commit and would likely not even bother checking if I was used to that scheme). Seeing `guix build' fail because upstream hopped tags is frustrating from a reproducibility angle, but it makes it somewhat easier to assign blame and move forward. Similarly, if we use git-version where we are unsure if upstreams play nice, we never claim to package a canonical "1.2.3", but a particular commit that advertises being "1.2.3" through other means, such as configure files. It would be obvious, that Guix always packaged that commit. > Rather, I think, the reason Guix keeps both the tag and commit ref is > simply that the tag could disappear from the repo.  (In my > experience, that's easy to do by accident when you clone a repo and > push it to a new location.  You have to fetch and push the tags > explicitly.) Changing locations are not an issue here as we don't have git mirrors. > If a tag ever *was* changed to point to a different commit, meaning > that the same version string now represents a different actual > version, then I think Guix would give that version a new name, such > as "1.2.3-new" or whatever.  I don't know if this ever actually > happened, but I think this is how Guix would probably want to deal > with it if it does.  Having one string represent two different actual > versions is just really terrible and I don't see Guix ever supporting > such a practice. Currently, Guix "supports" this practice by going from tags to (git- version base revision commit), i.e. doing what you'd expect it to do. I think we did find a few badly behaving upstreams by virtue of using tag and (hopefully) moved to git-version for all of those. The alternative proposal would support this practice by not caring about tags and let upstreams do as they please because they can't break our tooling anyway, YOLO. In a sense, we are trying to find technical solutions to social issues here. > [tangent follows] > > (A software developer might argue that two different commits actually > are the same version of the software, say for instance because only a > minor change in the build system or README file or such was made, > i.e. files that are considered "not part of the end-product," but in > Guix land I think we wouldn't let that fare.  Maybe an exception > would be made if it was proven that the actual package produced by > Guix from both commits will always be bit-identical.  Even then, > better not.) If the documentation is included in the end product (which it hopefully is), then yes, that hash would also change. If you change your gitlab CI yaml, because you typo'd hard and then the CI failed to build a release tarball, I think we as Guix can see that this is a one time thing while you're still young and move to the new commit. If you do it more often then yeah, no love from us. > P.S. I hope I'm actually helping to add clarity to the thread instead > of more confusion by adding my voice.  I was just skimming the ML, > found this thread interesting, and thought I might be able to add > clarity, because it seemed a little confusing. :-) At least imo your opinion helps, as it also helps me formulating my own ideas clearly. If there's a particular thing you're confused about, do not hesitate to ask :) Cheers