[Nix-dev] Thoughts: What about using aufs instead of symlinks + env vars?

[Marc Weber]

summary:
  * If this worked before I would have saved several days of work overall
  * unkown wether this will work on Windows / Mac (?)

olegfink asked on irc today why we use symlinks instead of bind mounts
or plan9ish mounts (I don't know what they are yet)

Eg aufs can be used to create a virtual file system. According to mount
this can even be done per process (?). You can add a directory to which
modifications will be written to as well (?)

Why should we evaluate using something like aufs and per process binds in nix(os)?
* less packaging effort required for some packages such as ptyhon [3]
* no fixing of shebang lines required (that's nice to for sharing code)
* no more worrying about rpath settings (I remember viric having issues
  with cmake and rpath)
* no more gcc wrapper hacks (?) skipping impure paths?
  armijn did a lot of work on adding cross compilation to nix.
  His outdated branch is still availible. I looked into it several days
  but its not my area of expertise. So finally I just isntalled gcc
  binutils into $out the default way (without using any wrappers) and
  avrgcc just worked.
* If store paths changes only (eg because you add a white space line to
  a builder by accident) or change an url (see my other previous post)
  nix could calculate the md5sum of the outpath and create a db
   /nix/store/foo-x                            [1] | 34587345
   /nix/store/foo-y-without-empty-builder-line [2] | 34587345
  So if someone else has to realise  [2] and already has [1]
  nix can create a hard link instead of fetching binaries or compiling
  the package again

pity: 
* You can't reuse store paths which have been compiled using
  aufs because references will point to /usr/share instead of
  /nix/store/*

Questions:
  Which is faster? using symlinks and looking up /nix/store/ or using
  kernel mount tables?

What are your thoughts?

Marc Weber

[3] I don't know exactly. I haven't investigated the
sqlalchemy-migration problem. Installing sqlalchemy and the
migration lib into the *same* target direcotry made it work.
I finally did the same for pygtk. Thus pygtk, pyobject, gnome-python and
gnome-desktop were installed into the same store paths see below.

_In depths description of the pygtk issue_:
The lib is imported by python in two phases:
import pygtk; pygtk.require 'version X'
The last command adds libPath/verisonX to its installation directiory. 
The problem is that pygtk doesn't know that depending libraries also
provding libPath/versionX are installed into different store paths.
so pygtk has to be patched to add libPath/versionX to all sys.path items
which can end up in many more "does directory exist" lookups than
it does on other systems. By using aufs you don't have to care you don't
even have to patch.