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.publi...@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.
>
--
