Re: Guix pull: avoiding "Computing Guix derivation"

[Edouard Klein <edou@rdklein.fr>]

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.toutoune@gmail.com> writes:

> Hi Richard,
>
> On lun., 13 mai 2024 at 20:52, Richard Sent <richard@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