[Nix-dev] [Want to commit this week] deepOverride replacement when callPackage is used

[Eelco Dolstra]

Hi,

On 09/02/2010 01:47 PM, Michael Raskin wrote:

> 	[Summary: right now it is hard to build a package with recursively
> replaced glib; there is a way that works - look at code snippets and
> comment on them.
> 	I see no reasons not to commit these changes in a couple of days after
> checking them on Empathy build, unless some problems with the changes
> are pointed out]
> 
> 	Soon after we had a discussion about avoiding deepOverride,
> all-packages.nix changed to callPackage style and the proposed solution
> stopped working.
> 
> 	Part one: gtkLibs220 has no __overrides. So gtk depends on default glib
> unless you basically copy-paste everything. Proposed solution
> (instantiation checked, gives the same unless you use overrides):

As far as I can tell this is not necessary.  When I introduced callPackage, I
actually took care that overriding packages in sets like gtkLibs is still
possible :-)

For instance, you can stick this in ~/.nixpkgs/config.nix:

  packageOverrides = pkgs: rec {
    gtkLibs220 = pkgs.gtkLibs220 // {
      glib = pkgs.gtkLibs218.glib;
    };
  };

This globally replaces the default glib by the old 2.22.x (from gtkLibs218).  I
assume this also works from within all-packages.nix.  You can use something like

  $ nix-store -qR $(nix-instantiate . -A firefox)

to verify that it uses only one glib.

Note that supporting overrides like these is exactly the reason why there is an
ugly self-reference in newScope, e.g.,

  gtkLibs220 = let callPackage = newScope pkgs.gtkLibs220; in { ... };

This is to ensure that (e.g.) gtk obtains its glib argument from the overrides,
if applicable.  A tricky consequence is that this override doesn't work properly:

    gtkLibs = pkgs.gtkLibs // {
      glib = pkgs.gtkLibs218.glib;
    };

because gtk will still use the un-overriden glib from pkgs.gtkLibs220.

-- 
Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/