Dear all, this question was asked several times. But >Computing Guix derivation for 'x86_64-linux'< annoys really.
Why do we need this so often? Of course, we need this, if we pull a new guix. If we do it, we know that it takes its time. But why do we need it with >guix system reconfigure< etc.pp.? We have a pulled guix locally and ready. That's the one we want to use! Well, I see that >guix system reconfigure< pulls new commits. But why? I don't want them. I want it to use my pulled guix. If it uses new commits, I'm forced to recompile the kernel et.al. - at least if >guix weather< is not good. If the pull is old, guix tells me this. Then it's my decision to pull it or not. Workarounds: 1. The last time, the weather was not good. Therefore, I looked up the commits in my subscribed channels and chose commits that are 2-3 weeks old, just after the last CVE. Then my weather was much better. This leads to Proposal 2. 2. Well, at the moment I wrote the commits into >~/.config/guix/channel.scm<. I hope that reconfigure respects this. But this ignores my pulled guix. This leads to Proposal 1. Proposal 1: Do not automatically fetch commits on reconfigure et.al. Use the pulled guix. PRO: We have a guix derivation ready to go on. AFAICS, we can use exactly this guix for the system, if we do not cross-install. PRO: Clear design. >guix pull< pulls new commits. All other commands don't do this - as long as channel commits are not explicitly given. OPEN: How to handle local trees (i.e. -L directory)? Well, they add new branches and leafs, maybe a new forest. They do not change the old forest at all. Most of the time, it contains only a few nodes or leafs. Than the addition should not take long. If it take to long, it's a hint to convert it into a channel. We may add a flag to the channel description. E.g. (use-newest? #t) Proposal 2: Set up a stable guix channel. I.e. a channel where all packages (or 99% of all and 100% of >important< packages) are build and tested by CI. Then its commit can be done automatically. PRO: We get stability. We get substitutes directly after >guix pull<. It saves many users a lot of compile time. NB: If there is a CVE, we should inject its solving commit into the CI queue with a high priority. Then CI checks and builds this commit as its next commit - possibly interrupting its previous target commit. Well, this should depend on the gravity of the CVE or inject, respectively. Proposal 3: Create a database (per channel) to look up files and get their packages, like https://www.debian.org/distrib/packages#search_contents Kind regards, S. Karrmann
