This incomplete draft draft uses simplifications and generalizations, no technical correctness is implied. This does not reflect the authors knowledge of the topic, it is just a draft to keep thoughts on a topic.
There is an experimental css-only lightbox in this post for the images. Over time it will be improved, for now you have to live with the issues.
On the infotropique mailinglist I recently mentioned that I am looking into frozen DAGs (Directed Acyclic Graphs). What does this mean?
Excurse: DAGs in Guix.
Quoting the Guix Manual "Invoking Guix Graph":
Packages and their dependencies form a graph, specifically a directed acyclic graph (DAG).
Visualy, how does this look like? For coreutils:
and for s-shell ("s"):
The TL;DR Version with inaccurate language is this: inputs (others would call them "dependencies") of a package.. Now we have the technical possibilities in Guix to keep multiple versions of a package around, but not necessarily installed in one profile at the same time.
A variable / procedure for a package in Guix is in most cases given just the name NAME, for example "
(define-public icecat (package ...))
in the case of icecat. This also means we keep one versions around, most of the time. Exceptions include compilers like Guile, GCC, etc. Generally old package versions are simply dropped. You can retrieve them from the git history of the repository but since they are often written with inputs pointing to just the latest version of the packages, you will run into problems eventually.
Alternatively you could pull an older guix version, make a profile with it and install the old version from this guix. The versions do not disappear, it just gets inconvenient to install them. From the linear history view (as experienced by a continous 'guix pull' without specifying commits) however they disappear.
If I remember the reasons for this correctly, it is because we thrive to keep the guix 'gnu/packages' tree maintainable by a small group of people and buildable by an CI in times and data volumes which do not create bottlenecks before a release, as well as try to keep the experience for users easy to upgrade and apply security updates in time.
As outlined above, the top-level package you are looking at gets a new hash as soon as a new version of one of its dependencies becomes available or is altered in anyway.