[Nix-dev] general design of nixpkgs - What about adding a dependency solver?

[Marc Weber]

Does the current way of managing dependencies make sense?

Example:
Today I tried compiling gimp (git version) because I think it provides
some nice features which will safe me some time. Things like non
destructive editing are coming.

Issues:
If I want to update gimp I also have to update gtkLibs. Easy going.
Then: gnome and pygkt are also passed to gimp.

Now the dependency hell is starting: Will something bad happen if gnome
and pygtk have been compiled with a different gtkLibs version than gimp
will be compiled with?

How to fix?

a) don't. Hope it works

b)
make pygtk and gnome be a function taking an gtklibs
argument?
(This means a lot of manual maintenance)

c)
Change default for gtkLibs in all-packages?
This means I run the risk of breaking other existing packages. I don't
want to test *everything* at the moment.


create a nixpkgs branch for c) only intentionally not trying to ensure
that all other packages depending on gtkLibs still build?

This solution works fine for user envs. But it doesn't work for
systemPath in NixOS. Well it does: If you start putting store path into
/etc/nixos/configuration.nix which have been built previously by 
using a different (maybe incompatible) nixpkgs branch..

So is this a design weakness in nixpkgs?

How can this be fixed? Using b) passing a pygtk argument to both: gnome
and pygtk seems to be promising. However this still does not unsure that
all the gtkLibs for gnome and pygtk and the gktLibs passed as buildinput
to gimp have the exact same version.


What do you think about implementing kind of general dependency resolver which
tries to do the right thing automatically?

Then you could write packages like gentoo, Ruby Gem users, Haskellers
(Cabal) or Eclipse plugin writers are doing:


Give a list of dependencies once:

  RDEPEND="java? ( virtual/jre )
          >=sys-devel/binutils-2.16.1
          >=dev-libs/nss-3.12.3-r1
          >=dev-libs/nspr-4.7.4
          >=app-text/hunspell-1.1.9
          >=media-libs/lcms-1.17
          x11-libs/cairo[X]
          x11-libs/pango[X]
          xulrunner? ( =net-libs/xulrunner-1.9.0* )"

  DEPEND="${RDEPEND}
          dev-util/pkgconfig
          java? ( >=dev-java/java-config-0.2.0 )"

and press a "try find a solution" button.


The basic Nix system is perfect: You can easily put a different system
on top of it providing this "try finding a solution" task.

Moreover suddenly it is possible to package Eclipse dependencies and
such.

I'm aware that this is not an easy task. However specifying a dependency
list would make nixpkgs more modular and a lot of passing of arguments
could be omitted in nixpkgs.

Marc Weber