updating list of substitutes

[Pjotr Prins <pjotr.public12@thebird.nl>]

Pretty much every time I want to install a package I get a search for

  updating list of substitutes 

being on a slow internet line this sucks (not everyone has fast
internet! Think outside the US/Europe where internet is often still
metered on mobile lines), besides installing the same software often
install a host of new versions of dependencies. I don't like the
system changing under me - that is not a reproducible setup.

Q1: Do we retain older builds of binaries for some time for download?

Q2: Can we switch off updating list of substitutes? A command line
    switch would do. '--no-update-supstitutes'

Q3: Would it be possible to version the list of substitutes and use
    that for (re)deployment? That way I can truely regenerate an existing
    system.

Pj.

On Sun, Apr 19, 2015 at 10:18:46AM +0200, Pjotr Prins wrote:
> On Sat, Apr 18, 2015 at 11:23:50PM +0200, Ludovic Courtès wrote:
> > Pjotr Prins <pjotr.public12@thebird.nl> skribis:
> > 
> > > Great :). I would make it a little clearer that this is
> > > 'bootstrapping' and hype it a little more that now there is no reason
> > > NOT to install Guix. Only 100Mb on your HDD.
> > 
> > Not sure how to do that, would you like to propose actual text?
> > The thing is, I want it to remain accurate and factual.
> 
> The current text is fine. 
> 
> > What do you meaning by moving a package with dependencies?
> 
> I am thinking about Nix-style closures. But it may only confuse
> things. I don't think the Guix manual covers closures.
> 
> > > BTW when Nix decided to go for a meta-database they lost something. I
> > > know it has good reasons (performance mostly) but it took away the
> > > self-containedness of packages. It would be nice just to be able to
> > > copy/del packages and rebuild the meta information. Do we have
> > > something like that? 
> > 
> > This part is the same as Nix.  The database is here to store meta-data
> > about store items, notably the list of references found in a store item.
> > Determining this list requires scanning all of the store item???s
> > contents, which takes time proportional to the number/size of files it
> > contains, so the database can hardly be avoided.
> 
> Yes, I understand. But would it be possible to regenerate the database
> from an existing /gnu/store? You can see I like to mess around with
> files ;). With closures a rebuild should not be necessary, but as a
> wary system administrator I know I will need it at some point.
> 
> Pj.
> 

--