I am getting really tired of looking at substitute-binary: updating list of substitutes from 'http://hydra.gnu.org'...
> What I have learned is that: > > 1. We now have a tar-ball install (awesome!) > 2. The DB is the authority > 3. We can't reconstruct the DB from the store > 4. Every release fixates the dependencies so if we know the exact > release we can recreate the same dependencies > 5. We reload the list of substitutes after a fixed time > > Correct? > > One more below on (5): > > On Tue, Apr 21, 2015 at 10:40:28AM +0200, Pjotr Prins wrote: > > > > Q1: Do we retain older builds of binaries for some time for download? > > > > > > Yes, but the amount of time is unspecified. > > > > > > On hydra.gnu.org it can be quite long in practice, so that would call in > > > favor of increasing the default TTL in ???guix substitute???. > > > > > > In the longer run, we need servers to advertise their TTL (someone > > > running ???guix publish??? may have a different TTL.) > > > > > > > Q2: Can we switch off updating list of substitutes? A command line > > > > switch would do. '--no-update-supstitutes' > > > > > > No. > > Let me rephrase. Can we have a more lazy approach towards fetching > substitutes? Rather than a fixed TTL we could fetch the latest list on > the first failed substitute. I expect, in practise that would save a > lot of downloads which turn out to be very slow, even on decent > internet connections. It also saves load on the build server. > > It does mean the initial binary/build overview on package install can > be wrong but since we retain binaries for a long time (in practise) it > would be more likely to change between releases anyway. A simple > message would do: > > INFO: failed download of substitute XXX (you may want to pull the latest > release) > INFO: substitute list downloading... > INFO: updated substitute list. The following packages will now be built: > 1. etc etc. > > I think this is actually safer and fairer than a TTL. > > Pj. > > --
