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 0Hg1NqvC4WGpLgAAgWs5BA (envelope-from ) for ; Fri, 14 Jan 2022 19:36:27 +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 mAPmMqvC4WE4IwEAauVa8A (envelope-from ) for ; Fri, 14 Jan 2022 19:36:27 +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 2F4C21CCB0 for ; Fri, 14 Jan 2022 19:36:27 +0100 (CET) Received: from localhost ([::1]:51766 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n8RR3-0005Di-KS for larch@yhetil.org; Fri, 14 Jan 2022 13:36:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56256) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n8RQg-0005D0-9p for bug-guix@gnu.org; Fri, 14 Jan 2022 13:36:02 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:45216) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n8RQg-0004dY-00 for bug-guix@gnu.org; Fri, 14 Jan 2022 13:36:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n8RQf-00018g-VN for bug-guix@gnu.org; Fri, 14 Jan 2022 13:36:01 -0500 X-Loop: help-debbugs@gnu.org Subject: bug#53224: Cookbook recipe about profile collisions Resent-From: Leo Famulari Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Fri, 14 Jan 2022 18:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53224 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Received: via spool by 53224-submit@debbugs.gnu.org id=B53224.16421853334335 (code B ref 53224); Fri, 14 Jan 2022 18:36:01 +0000 Received: (at 53224) by debbugs.gnu.org; 14 Jan 2022 18:35:33 +0000 Received: from localhost ([127.0.0.1]:38119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8RQC-00017o-Ji for submit@debbugs.gnu.org; Fri, 14 Jan 2022 13:35:33 -0500 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:52415) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n8RQB-00017Y-6V for 53224@debbugs.gnu.org; Fri, 14 Jan 2022 13:35:31 -0500 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 26F8B3200E90; Fri, 14 Jan 2022 13:35:25 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 14 Jan 2022 13:35:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=famulari.name; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-transfer-encoding:in-reply-to; s=mesmtp; bh=e5flG6nYtfOmMFZl6fRBy3jf+5ogTCuhWVShMROat5Q=; b=utjOqhI2f00D 88D4N0zL4gukYK6PMWIPdVTCtG3mUvo6nmYRPGFPqEFF7VGYVhxCDxByqzgzI7Ou 88HtntDYOmb2lEuo5cBUDPM3t2OdbKXqMb33rZN15OW7x0U/EmgcL3yLAMv7zkmn E9itI87psFUBqujcbdRQS6gwF7PynCY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=e5flG6nYtfOmMFZl6fRBy3jf+5ogTCuhWVShMROat 5Q=; b=UY744wXzaxamCk4J74argGN7RKAfh/cOisLBqMSczyq6CZRulC7A/Y/Ep MVr6VNHo9NNFvFv7PDbDHEy6FCFtbaVljij1D/VHnv0W7r+TydHjcG+gqlthN82v jsuWwRRWfqgbrFe8Z2QRVVepvoWNhywU7oK8HUNn+WlE+9V2oEq0xL61uVLdaS/U rwvQ3zpGrpLI6nZSgHAn18x79o7N0itJtwFB8kb+wIDDUl5gs27JzU5lhHBS+D4r RK2gGAOaSiKROKxEBfLBdUi9CfbuYOZHErHv41PPBK25XJ3V3wZ/lJRKWbDTeubk vV7fkhssM2rQH1mgAe70DtsMxE70Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrtdehgdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfhfgggtugfgjgesthekredttddtjeenucfhrhhomhepnfgvohcu hfgrmhhulhgrrhhiuceolhgvohesfhgrmhhulhgrrhhirdhnrghmvgeqnecuggftrfgrth htvghrnhepueehjeekkeeuudffueefjeekjeehhedvhefghfevteffffetffdvfeeuieel veefnecuffhomhgrihhnpehgnhhurdhorhhgpdgvgigtrghlrghmuhhsrdgtohhmnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheplhgvohesfhgr mhhulhgrrhhirdhnrghmvg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Jan 2022 13:35:20 -0500 (EST) Date: Fri, 14 Jan 2022 13:35:18 -0500 From: Leo Famulari Message-ID: References: <87v8ym4sav.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87v8ym4sav.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: 53224@debbugs.gnu.org, Matt Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: "bug-Guix" 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=1642185387; 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:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=e5flG6nYtfOmMFZl6fRBy3jf+5ogTCuhWVShMROat5Q=; b=Fh9wn1TIWUS5efvPz1NLdVjA4jS2CgX27fzyo2QhbSOqbuP7q0Q4VnATcDY4e+sxAEP5fe TWz5BO0eNlULSq/on1AeslQHqfTm5mqUSG0LJnF4CTuBiRMBv4XQ5dZRu5EyXlavGTBFGF 0ZNbuph2caxiP5RG5HYixu7MFAjhI4mYZQDf79CTW0OEYGQMvJJiQS/84JY3r6FX3YY33J sBMKuWzBzqvS9OEzv4gl5RCgB7U4HXgYiK6W5BYOUdHNVI6DPs4Epxl4rsKjD9oJZLHYCK i0cv6yqvgWEAPBd4G5yygKPN9iIshxsjhVCd6icI/5DDuRYha+wrnZyH4OJuAQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1642185387; a=rsa-sha256; cv=none; b=jww57goRSvjqOcwgXyEKKAWjRy5f1gpKYTV8tKORqDKhijm6zVWy4s4fx4Dxhjjcd3x4WO kElg8FHpwtBrsvTY2p0VVGpiw3AxA9tdHOUcFk3YNxOG4LPt2cKUFA4k+FygYBziWA/gw7 Ak1g2c7VNHmPhzEUm/B9599ebvVeCuE421UC2/Y1c6CPYN2I9kkjMeE7ZqwPrENOVPXM5+ cXj/BtW0EMnfpk2rYAB6ztDZE6tQeRG3F36fj3+4yQhaWzFZlGw+TpsG7X4eKTOamwAo8m kpjS+nexOsh6PLiu8jI8E4ytjKMgRj4q3Im6x6/Dt7aZwviFLFnompeRtHcg3Q== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=famulari.name header.s=mesmtp header.b=utjOqhI2; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=UY744wXz; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.72 Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=famulari.name header.s=mesmtp header.b=utjOqhI2; dkim=fail ("headers rsa verify failed") header.d=messagingengine.com header.s=fm1 header.b=UY744wXz; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 2F4C21CCB0 X-Spam-Score: -3.72 X-Migadu-Scanner: scn0.migadu.com X-TUID: xtYGtt3bhaH6 On Fri, Jan 14, 2022 at 09:47:52AM +0100, Ludovic Courtès wrote: > > Recently, Matt pointed out that profile collisions can be confusing and > > difficult to resolve: > > > > https://lists.gnu.org/archive/html/guix-devel/2022-01/msg00115.html > > I don’t see the words “profile” and “collision” here; maybe that was > upthread? I pointed to this blog post, which was linked from that email: > > Specifically see this blog post: > > http://excalamus.com/2021-10-06-guix-debug.html It's the story of an attempt to learn what the "conflicting entries" message means and how to resolve it. > Currently, on profile collisions, the error message shows where the > collision originates and a hint on how to work around it. Perhaps the > hint is sometimes wrong (in which cases?), or perhaps it’s too terse? > Can it be improved? The hint is perfectly clear, when you understand "profiles" and "propagation". It's like I said later in my message: People use Guix without knowing very much about it. That's surprising to me, because I started using Guix *because* I learned about profiles and how they are used: it's one of the core innovations of Guix / Nix, to implement unprivileged package management. But nevertheless, people are using Guix without understanding how it works. And it's hard to learn about Guix when you are dealing with a profile collision that you don't understand at all. For many people, that is not a good moment to start learning. On top of that, profile collisions are an error state that we can't fix as a bug: we have to give users the knowledge to resolve the collisions themselves. For example, the blog post that I linked to ends with "Lessons Learned", which includes this: ------ What is a profile? A profile is a directory of symlinks located at ~/.guix-profile. Propagated inputs can cause conflicts Propagated inputs are treated somehow differently. It's still not 100% clear how or why, but it's good to know they're a potential source of errors. ------ This person spent a lot of time trying to understand the situation and writing the blog post, but their understanding is still rather weak. That's why I propose a Cookbook chapter that specifically addresses profile collisions, to help new users go from "oh no, an error message" to "aha!" > The definition of what a profile is is another topic. Currently the > term “profile” is defined in “Getting Started”: > > https://guix.gnu.org/manual/en/html_node/Getting-Started.html#index-profile > > It’s very much defined in passing though. How can we improve on that? I think this part of the manual is fine and can stay as it is. > In some early talks we had illustrations of the symlink forest of a > profile borrowed from Eelco Dolstra’s own talks on the matter; see for > instance p. 17 of . I > stopped using it because I think those symlinks are an implementation > detail and it doesn’t help to focus on symlinks (and hashes and all > that) when giving an overview of the tool. Now, perhaps that > illustration could be useful in the manual. > > WDYT? The illustrations of the symlink forest were *extremely* helpful to me when learning how Guix implements unprivileged package management. I think that later talks from the 2015-2017 era refined the illustrations to be even more clear. I'm sorry if the use case for my proposal is still unclear. I can work on the Cookbook chapter myself.