bug#24993: System installer grows brittle with time

[ludo@gnu.org (Ludovic Courtès)]

Leo Famulari <leo@famulari.name> skribis:

> On Mon, Nov 28, 2016 at 08:45:39AM -0900, Christopher Howard wrote:
>> I was able to make more progress with the --substitute-urls=... option
>> you mentioned. However, later, when the system is building the
>> gnupg-2.1.13 drv (I did not pass --fallback, but it still builds stuff)
>> one of the 36 check tests fails ("tofu.test"), causing the build to fail.
>
> It will build stuff if it can't find a substitute (not an error).
> '--fallback' is only required when substitution fails (an error).
>
> That particular test failure was a bug in GnuPG's test suite that we
> worked around:
>
> http://git.savannah.gnu.org/cgit/guix.git/commit/?id=d404a6f9711c8dcc1cc6cf55d8c07901aa450192
>
> Code with an expiration date is very annoying!
>
> It sounds like you will need to use `guix pull`.
>
> What do others think? Should we mention `guix pull` in the installation
> documentation?

I’m not a fan of this, for the reasons you gave.

> I'm skeptical for reasons described upthread. I think the real bug is
> that the installation image becomes brittle as time passes (so I changed
> the subject of my reply).

Right.

A solution that some suggested before (but for other reasons) would be
to include more packages on the installation image.

The image is currently slightly below 1G, but we could add binaries for
GTK+, Python, and a few other relevant packages.  We’d need to find out
what makes sense and how much extra space it would take.

> this become less pressing when we have more storage space and can store
> substitutes for a longer period?

True.

The mirror has room to store things for a long period of time, but
there’s a subtle problem with non-deterministic builds: the mirror might
cache a narinfo and the corresponding nar, then the narinfo leaves the
cache, then a new narinfo is fetched from hydra.gnu.org, and at this
point the mirror has a narinfo advertising a hash that doesn’t match
that of its nar.

Of course the solution to this is reproducible builds, but the fact is
that we still have a bunch of non-reproducible packages.

I recently lowered narinfo caching time in the mirror because of that:

  http://git.savannah.gnu.org/cgit/guix/maintenance.git/commit/?id=caaeb7bea3515e7ef45e33e5e75674f7b72c2f06

… but that’s not great since it means the mirror can lose narinfos
quickly, even though it has enough room to store them.

Ideas?

Ludo’.