From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: updating list of substitutes Date: Wed, 22 Apr 2015 13:46:35 +0200 Message-ID: <20150422114635.GA24566@thebird.nl> References: <20150421064525.GA15795@thebird.nl> <87a8y1q49z.fsf@gnu.org> <20150421084028.GB16564@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:39862) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ykt7u-0001NT-Su for guix-devel@gnu.org; Wed, 22 Apr 2015 07:47:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ykt7r-0003N5-I1 for guix-devel@gnu.org; Wed, 22 Apr 2015 07:47:34 -0400 Content-Disposition: inline In-Reply-To: <20150421084028.GB16564@thebird.nl> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Ludovic =?iso-8859-1?Q?Court=E8s?= , guix-devel@gnu.org I wish to thank you guys for bearing with my dumb-ass questions. I think Guix is totally awesome. I have been tracking Nix for a long time and Guix makes me happy where Nix did not. Please keep on answering me. First because I am learning and second because we are building a record on this ML for others to see. Your responses have been very valuable, including Ludo creating the tar-ball install and Ricardo's mail on the database layout. You should know I have at least three hats, as system administrator, as software developer and as scientist - these roles have conflicting goals and demands which is why I can discuss direct state modifications in the store on one end and ask for reproducible software on the other ;). 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.