Hi, On Fri, 14 Jan 2022 at 10:02, Ludovic Courtès <l...@gnu.org> wrote:
> 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? I do not know how it could be improved since it is often case per case. For instance, recently we had a collision for python-numpy and the fix was to introduce python-numpy-next. That's said, to me the origin of the collision is often enough for resolving. However, indeed the user must have a clear understanding of Guix profile and propagation. Therefore, an entry to the Cookbook explaining what does it mean and where to look appears to me a good idea. > 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? > > 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. Well, I do not want to drift the initial message. I am just keeping the rolling ball. :-) In the tutorial I am preparing for JRES, I am doing this way, as a dialogue (below). Basically, it is how I am somehow explaining to the few users I have here, with various background. This cannot go to the manual but maybe it could be useful or worth for the Cookbook. To me, what is an implementation detail is all the dance with /var/, the generations, the garbage collection, etc. But the fact that a profile is symlink pointing a directory with the structure of /usr/ and containing all the environment variables is not an implementation detail. It appears to me a core concept to switch from traditional distro with only one /usr/ to Guix and how to compose many /usr/. Alice: Where are my packages? Bob: Installing a package ends with this hint ...snippet... Alice: Ah, I am confused Bob: Well, $HOME/.guix-profile is thus the default profile Alice: What does it mean? Bob: Look at guix package --search-paths -p $HOME/.guix-profile Alice: I see, but what is this $HOME/.guix-profile Bob: Look at: file $HOME/.guix-profile Alice: Ah, right. My conclusion is: - a profile contains the environment variables - a profile is a symlink Bob: Correct. Alice: But a symlink pointing to where? Bob: Look at: readlink -f $HOME/.guix-profile Alice: It points to a store item, but what does it mean? Bob: Look at: file $(readlink -f $HOME/.guix-profile) Alice: Ah right. My conclusion is: - a profile points to a directory item in the store Bob: Correct. Alice: What is inside this directory Bob: Look at: ls $(readlink -f $HOME/.guix-profile) Alice: Oh, it looks the same hierarchy as the usual and well-know /usr/ Bob: Correct. Alice: What does it happen when I type python3 I just installed Bob: Look at: which python3 Alice: Ah right. Is the binary really in the directory item above? Bob: Look at: readlink $(which python3) Alice: Oh right. A profile points to store item which points to other store items. Bob: Correct. Alice: I guess these other store items have also an /usr/ hierarchy, right? Bob: Correct. Do you know how to check that? Alice: ls $(readlink $(which python3)) Bob: Correct. Alice: I summarize. A profile is: - a symlink - which points to a store item - which points to many other store items - and all have the structure hierarchy of /usr/ Woo, it is a forest of symlinks! ... image ... Cheers, simon
