[Nix-dev] Checksum errors trying to install ghc-6.6.1

Eelco Dolstra eelco at cs.uu.nl
Sat Jun 2 22:53:48 CEST 2007


Sean E. Russell wrote:
> On Saturday 02 June 2007 13:17, you wrote:
>> On Sat, 2007-06-02 at 19:08 +0200, Armijn Hemel wrote:
>>> You can fix this by replacing the hash sum with the hash sum that was
>>> expected in the Nix expression for GHC.
>> Just checked the fix into subversion. The two tarballs had a 807 byte
>> size difference, which could be caused by using some other packaging
>> options. According to diff the contents are the same.
> 
> Does 'nix-env -u' cache any information about the hashcode?  

No, it doesn't cache anything.  However, assuming that you edited the hash code
in a checkout of the Nixpkgs tree, then you have to tell nix-env to use that
checkout, like

$ nix-env -f /path-to-nixpkgs -u ghc

I'm guessing that your default Nix expression for installations (~/.nix-defexpr)
points at the channel download.

> I did
> change the hashcode directly in the recipe, but subsequent install 
> attempts kept using the old hash code.  What is the purpose of the 
> *.drv files?

The *.drv files are basically a compiled form of Nix expressions, with all high
level functionality (like functions) compiled out.  Each drv (derivation) file
uniquely describes a single build action, along with the store paths of all
dependencies (sources and other drvs).  Drvs are not usually very interesting to
users, but they can be very handy because they give a handle on source build
actions.

For instance, suppose that you want to rebuild your copy of Firefox from source
on another machine, you could do something like this:

$ nix-store -qd $(which firefox)
/nix/store/jl9sy2979ig9brylghmlwg2p1ij1gsyg-firefox-2.0.0.3-with-plugins.drv

$ nix-copy-closure --to username at remotemachine \
  /nix/store/jl9sy2979ig9brylghmlwg2p1ij1gsyg-firefox-2.0.0.3-with-plugins.drv

and then on the remote machine do

$ nix-store --realise \
  /nix/store/jl9sy2979ig9brylghmlwg2p1ij1gsyg-firefox-2.0.0.3-with-plugins.drv

This is basically what happens in our build farm: there is a central machine
that does a nix-instantiate on top-level/build-for-release.nix, and then
distributes the closures of the *.drvs over the build machines.

Or if you want to see the entire build time dependency graph:

$ nix-store -q --tree $(nix-store -qd $(which firefox))

-- 
Eelco Dolstra | http://www.cs.uu.nl/~eelco



More information about the nix-dev mailing list