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.