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. _______________________________________________ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev
