From: Leo Famulari <leo@famulari.name>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 53224@debbugs.gnu.org, Matt <matt@excalamus.com>
Subject: bug#53224: Cookbook recipe about profile collisions
Date: Fri, 14 Jan 2022 13:35:18 -0500 [thread overview]
Message-ID: <YeHCZgO5c+I36Flr@jasmine.lan> (raw)
In-Reply-To: <87v8ym4sav.fsf@gnu.org>
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 <https://guix.gnu.org/guix-fosdem-20140201.pdf>. 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.
next prev parent reply other threads:[~2022-01-14 18:36 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 0:11 bug#53224: Cookbook recipe about profile collisions Leo Famulari
2022-01-14 8:47 ` Ludovic Courtès
2022-01-14 12:02 ` zimoun
2022-01-14 18:35 ` Leo Famulari [this message]
2022-01-17 14:16 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YeHCZgO5c+I36Flr@jasmine.lan \
--to=leo@famulari.name \
--cc=53224@debbugs.gnu.org \
--cc=ludo@gnu.org \
--cc=matt@excalamus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).