[Nix-dev] Package maintainer coordination problem and Nix

Mads Lindstrøm mads_lindstroem at yahoo.dk
Sun Jul 19 09:53:45 CEST 2009


Hi

I am new to Nix, so my comments below may be unfair. Please correct me
if they are. I am writing this, as I was surprised to find, that Nix do
not alleviate the dependency hell as thoroughly as I thought.

One major point of Nix is that it prevents the "DLL hell" - or the
dependency hell. And this does seem to be true to a certain extent.
After all, I can have subscribe to two different Nix channels and they
will not interfere with one another. And older application will not
magically stop functioning, because I upgrade some library.

That said, when looking at the way packages are organized in the Nix
subversion repository
(https://svn.nixos.org/websvn/nix/nixpkgs/#_nixpkgs_), package
maintainers must still do as much coordination as package maintainers in
traditional Linux distributions. That is, if I upgrade Glibc in the
subversion repository, I risk braking packages that depends upon Glibc.
In other words, if package X depends upon library Y, it is _not_ stated
explicitly which version of library Y. Rather it depends upon the
version which happens to be in the Nix repository. And when Y is
upgraded, we can only fold our hands and pray, that X is not affected
badly.

This leads me to the question, is Nix specifying dependencies optimally?
If each package, in the Nix subversion repository, explicitly stated
which versions of packages it depended upon, then upgrading library X
would be safe. Packages depending upon X would keep using the old
version of X, until somebody or some automated process had verified that
the package would work with the new version of X.


Regards,

Mads Lindstrøm

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20090719/eeacb2ff/attachment.bin 


More information about the nix-dev mailing list