>From my understanding (which may be terribly incorrect), hard links would cause two problems during the hash-scanning phase of a nix build:
1. At least as of Eelco's thesis, we were ignoring hard links in the canonicalization of store paths. That means that after a build, any hard-linked files will no longer be linked 2. Even if we did keep track of hard links during canonicalization, it would be fairly difficult if not impossible to resolve runtime dependencies. Nix would need to find the inode of the hard link and scan all store outputs for files with that inode, and if it finds more than one it will probably have to consider them all runtime dependencies of the current output, unless there's a way to determine which file was the earliest of a set of hard links. The canonicalization of symlinks, on the other hand, contains the path pointed to so hash scanning finds the runtime dependencies fine. ~Shea > > Isolating aspects of the original mail: > > On Sat, 24 Sep 2011 14:36:20 +0200, Florian Friesdorf <f...@chaoflow.net> > wrote: >> If ./bin/python is a symlink, we have currently a problem and PYTHONHOME >> would be a solution, if python is a real file, we do not have a problem. >> >> So instead of symlinking the python executable, nix-env should be >> instructed >> to hard-link it - is this possible? > > Why is nix using symlinks to link files in the nix store? > Would switching to hardlinks break something? > > - symlinks in case of whole directories > - hardlinks for individual files > > -- > Florian Friesdorf <f...@chaoflow.net> > GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 > Jabber/XMPP: f...@chaoflow.net > IRC: chaoflow on freenode,ircnet,blafasel,OFTC > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev