Re: updating list of substitutes

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

On Tue, Apr 21, 2015 at 11:19:58AM +0200, Andreas Enge wrote:
> On Tue, Apr 21, 2015 at 10:40:28AM +0200, Pjotr Prins wrote:
> > How do I recreate the exact same system from Hydra? Even now if I
> > install the exact same Ruby-2.2.1 it will install different packages
> > compared to yesterday.
> 
> I am lost here. If you use a fixed release or git commit of guix, ruby-2.2.1
> should be the same yesterday and today.


ls /gnu/store/*ruby-2.2.1*
  /gnu/store/gy1dnlh6qhwd40admi3b1mr4r9cn8bww-ruby-2.2.1

ls /var/guix/profiles/per-user/wrk/guix-profile-2-link/bin/ruby
  /var/guix/profiles/per-user/wrk/guix-profile-2-link/bin/ruby -> /gnu/store/gy1dnlh6qhwd40admi3b1mr4r9cn8bww-ruby-2.2.1/bin/ruby

A few days later I install ruby-1.8.7 followed by

guix package -i ruby-2.2.1

The following package will be upgraded:
   ruby 1.8.7-p374 -> 2.2.1     /gnu/store/z8kf6hgln4a7xf68pdnlibl3vcg5rl15-ruby-2.2.1

The following derivations will be built:
   /gnu/store/7k8nsgpvaafljk1wcnpiq3sm0vns64ck-profile.drv
   /gnu/store/b8pasb4kj50x696bln6jpq4myhzkbrg0-ca-certificate-bundle.drv
   /gnu/store/5hnj1f5i41a6vp4xshhrzqcf27vaf0y7-info-dir.drv
The following files will be downloaded:
   /gnu/store/z8kf6hgln4a7xf68pdnlibl3vcg5rl15-ruby-2.2.1
   /gnu/store/xgfynxf3nscq41n27mnd1lf1hb21fc7w-openssl-1.0.2

So openssl has changed the install. That is not reproducible installs
in my book.

> The only thing that could happen, if I understand things correctly, is that
> with non-deterministic builds and assuming that ruby-2.2.1 has been garbage
> collected and rebuilt on hydra, we would have a new store item on hydra
> with the same directory name (including the hash), but different content.
> However, if your machine has kept the old package, it should not be
> redownloaded, as it is the hash in the directory name that counts and not
> some hash over its contents. The solution here would be deterministic builds.
> 
> As I understand Ludovic's answer, the database cannot be regenerated because
> the store may contain corrupted items from a failed and aborted build. Adding
> a package to the database in a last step appears to ensure atomicity of the
> operation.

Yes. In that case, we should make sure that we know an atomic build
has been completed - also outside the DB.

I am not saying what guix does is wrong. I am saying there are
instances where you WANT to rebuild the DB.

Pj.