[Haskell-cafe] install-dirs on Mac OS X
markl at glyphic.com
Thu Dec 24 13:10:33 EST 2009
First, we must look at how Apple intends the various Library directories to be used. Please see the Apple docs on it[* link below]. Essentially, /Library is the Mac OS X equivalent of /usr/local.
> However, I would be opposed to storing anything in /Library or /System. Those are for system use and sysadmin experience tells me never to mess with the system installs.
You are only partially correct. /System/Library is for system installed pieces (those that come with OS X), /Library is for things that are available system wide, but have been installed after the OS, by the user. In particular, if you install Perl packages that don't come with OS X, they will end up in /Library/Perl. The same is true for Python and the other languages. /Library is the same place all sorts of user installed things go: MySQL components, video decoders, printer drivers, just to name few. Basically, anything that the user installs and expects to be available to all accounts is put there.
So I agree, it would incorrect to ever touch /System/Library - and I'm not suggesting that we do. However, it seems completely in line with Apple's intended usage to put things in /Library.
> if anything happens in /Library or /System then it has to go through the framework packaging system IMO,
This is not a requirement of /Library at all, and NONE of the other language systems on Mac OS X follow it. That is - none of them use Mac OS X's framework system for packages installed by the user. All of them use their native packaging layout. I suggest that we follow suit and use cabal's file layout.
> Overall, I'd like taking the cue to break things out by version number and then have some symlinking (or tool) in order to select one of many installed versions.
As I mentioned, cabal already does this with a per compiler and version subdirectory with the package directory itself. It seems excessive to duplicate it again. The idea from cabal, as I understand it, is that the parts of a package that are not compiler or version dependent are installed only once. Only the compiled lib files are installed multiple times, once per version/compiler.
> Besides, if we used something like a $HASKELL_PATH, or a tool for querying and recording installation paths, then it doesn't really matter where the default is since people can choose their own. All that matters is the structure of the tree rooted there.
For GHC, there is the ghc package system, and that takes care of all this already. And, it doesn't even require consistent package layout (!). So, not matter what we pick here, users will always be able to accommodate personal preference or special situations easily. I don't know about the other Haskell runtimes.
> Again, it's good not to mess with system internals (where GHC is the "system" here). In general we *want* Cabal to install things in a different location than the GHC base libraries.
Yes- that is what I was suggesting. I believe GHC should continue to put it's packages within it's Framework bundle. I was suggesting that cabal installed packages go under /Library.
> Those languages ---Perl, Python, Java--- are all used internally by the OSX system itself in order to run startup scripts, maintain the system, etc. That is, they are provided *by* the system, *for* the system. Users are free to use them, but they should not alter them in any way.
This isn't quite true. It is expected that users will install additional packages for those languages, explicitly for use with the version of those languages provided with the OS. In such cases, the standard place for such installs, is /Library (if made available to all users of the machine, which is the common default for such packages.) Of course the system installed set of packages for such languages are never touched, and live under /System. This is exactly the same state of affairs I'm proposing for Haskell.
[*] The Apple guidelines for the /Library and ~/Library files are here:http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFileSystem/Articles/LibraryDirectory.html#//apple_ref/doc/uid/20002282-BAJHCHJI
mark at glyphic.com
More information about the Haskell-Cafe