Hi, Matthew Gruen wrote:
How would this interact with the absence of symlinks on Windows?
Since the index tarball is never unpacked on the client's filesystem, only cabal needs to know about it, and it is backwards/forwards compatible.
What's the benefit of using a tarball then, if some developers wouldn't be able to reasonably untar it. Duncan proposed to use tarballs with symlinks to structure local build trees, and if one can untar the tarball to get actual symlinks, this sounds great. One could have all kinds of intermediate layouts by putting partly symlinks and partly cabal files into the file system, or the tarball, or both. But I fear that on Windows, this would not work (or at the very least cause great troubles), so this seems to be an unnecessarily introduced platform dependency. Some kind of index file in a text format like Antoine proposes would be much more portable, and nearly as useful. Lars Viklund wrote:
Note that NTFS has supported all kinds of links, sym- and hard-, since Vista and up, so I guess you're referring to exotic filesystems like FAT32, or slow-to-adopt environments.
I refer to my experience that a symlink created by cygwin only works for cygwin-mediated filesystem access but not for filesystem access through the native Windows API. Therefore, I would not expect to be able to "tar -xzf" a symlink-containing tarball with my cygwin tar, and follow the link in the Windows explorer, say, or the file open dialog of my Windows editor. (I was not aware that NFTS supports symlinks, though. How would I access this feature on a Windows machine?) Tillmann