Thank you both for this detailed explanations. I think I have a better grasp at the problem. Keep in mind that I never not dive into guix's internals. I just
- had previous experience with Gentoo and Source Mage (anyone remember this distro ?) who did some interesting steps towards reproductibility back in the day - knew what a Merkle dag is - read the manual and dived in with an overconfidence in my understanding of how this all works. To simplify the problem somewhat, bear in mind that a very good first step would be to avoid the "Computing Guix derivation" step, once it's been done already once and its result is "nothing to do". If that could happen, I could just run it as root once (4 minutes of downtime a week is manageable) and let the other users enjoy my cache. Simon Tournier <zimon.touto...@gmail.com> writes: > Hi Richard, > > On lun., 13 mai 2024 at 20:52, Richard Sent <rich...@freakingpenguin.com> > wrote: > >> You're correct. This solution wouldn't be sufficient to avoid "Computing >> Guix Derivation" for every possible A or B. To my understanding it could >> reduce the frequency this occurs. > > [...] > >> Assuming D changes significantly less frequently than A, B, C..., I >> would think this should be something we could feasibly substitute (at >> least for recent D and Z). > > Well, the package ’guix’ has changed 14 times over the past year. > Therefore, this D cannot be this package ’guix’, IMHO. > > $ git log --format="%cd %s" --since="1 year ago" | grep 'gnu: guix: Update' > Mon May 13 18:22:53 2024 +0200 gnu: guix: Update to 7ca9809. > Tue Mar 12 14:27:01 2024 +0100 gnu: guix: Update to 4c94b9e. > Mon Mar 11 23:14:37 2024 +0100 gnu: guix: Update to 8f4ffb3. > Sat Dec 2 15:37:44 2023 +0100 gnu: guix: Update to 1.4.0-16.aeb494322c. > Thu Nov 30 07:15:36 2023 +0100 gnu: guix: Update to 1.4.0-15.e0885fcfbb. > Thu Nov 9 10:42:55 2023 +0200 gnu: guix: Update to a60ff46. > Fri Oct 6 12:26:44 2023 +0200 gnu: guix: Update to e863274. > Thu Sep 28 11:44:08 2023 +0200 gnu: guix: Update to d0438fc. > Mon Sep 18 12:31:52 2023 +0200 Revert "gnu: guix: Update to > 1.4.0-11.658de25e99." > Mon Sep 18 06:49:46 2023 +0200 gnu: guix: Update to 1.4.0-11.658de25e99. > Tue Aug 22 21:30:49 2023 +0200 gnu: guix: Update to 1.4.0-10.4dfdd82210. > Tue Aug 22 11:17:52 2023 +0200 gnu: guix: Update to 30355c1. > Mon Oct 2 09:28:02 2023 +0200 gnu: guix: Update to 1.4.0-12.b9fae146d6. > Mon Aug 21 18:44:49 2023 +0200 gnu: guix: Update to 0e6215a. > Fri Jun 9 22:11:14 2023 +0200 gnu: guix: Update to 44bbfc2. > > > Maybe I have a bad practise but here my “guix pull” history: > > $ guix pull -l | grep Generation > Generation 1 nov. 17 2023 13:18:58 > Generation 2 déc. 11 2023 10:55:51 > Generation 3 févr. 02 2024 01:56:52 > Generation 4 mars 25 2024 18:22:25 > Generation 5 mai 13 2024 19:28:31 (current) > > Therefore, I am not convinced that replacing "Computing Guix derivation" > (build-aux/build-self.scm) by the package ’guix’ would be robust enough. > > (Assuming another package ’guix’, lighter e.g., without requiring the > test suite, etc.) > > All that said, any experiment – even if it appears at first clunky – is > very welcome! This part will be improved only if there is a collective > effort / discussion / try, IMHO, i.e., by challenging the status quo. :-) > > Cheers, > simon
