[Nix-dev] Re: Package maintainer coordination problem and Nix

Peter Simons simons at cryp.to
Sun Jul 19 11:48:30 CEST 2009


Hi Mads,

 > I was surprised to find, that Nix do not alleviate the dependency
 > hell as thoroughly as I thought.

yes, statements like those should be taken with a grain of salt. It's
mostly propaganda. Basically, Nix does not affect the package dependency
structure in any way whatsoever. A package that's being installed via Nix
has the exact same dependencies it would have if you'd install it on
Gentoo, Debian, or any other distribution. What can be said for Nix is
that it is particularly good at detecting unspecified dependencies.
Arguably, the package dependency structure expressed in nixpkgs is more
complete and accurate than that of other distributions, but it's by no
means simpler, easier to maintain, or easier to understand.


 > If each package, in the Nix subversion repository, explicitly stated
 > which versions of packages it depended upon, then upgrading library X
 > would be safe.

That can easily be done. Packages *can* depend on specific versions of
other packages. While possible, however, this kind of setup is
undesirable. Consider a package that depends on Python 2.4. Now there is
another package that depends on Python 2.5. If you install those two
packages, you'll end up having two different versions of Python's
installed. If you consider this phenomenon for a complete Linux system
with OpenOffice and Firefox and whatnot else, then you'll have an
installation that is incredible redundant.

In truth those two packages don't really depend specifically on Python
2.4 or 2.5. It's more likely that they'll work fine with any version of
Python newer than, say 2.0. Then again, Python 3.0 might break them, so
what you really want to specify is a version range:

  "python>=2.0 && python<=3.0"

Nix can do all that. The reason why dependencies aren't specified that
way isn't technical in nature. The problem is just that figuring out
those facts is a hell of a lot of work. :-)

Take care,
Peter




More information about the nix-dev mailing list