Haskell Platform 2014.2.0.0: Linux installation

[Travis Cardwell]

Dear Haskell Platform team,

Congratulations on the release!

I just installed from source (on Debian Wheezy) and have some feedback
that I would like to share.

1. I do not think that installing into /usr/local/haskell is good
organization because it mixes Filesystem Hierarchy Standard (FHS)
directories (bin, lib, share, etc.) with non-FHS directories (haskell in
this case, but go is another example).

I install local software into a /usr/local/opt directory, since such usage
is analogous to that of /opt (and reserve /opt itself for package-managed
content).  I wrote about this in more detail here:
http://www.extellisys.com/articles/usr-local-opt

One can always use the "--prefix" option when building from source, of course.

2. Until now, I have installed minimal Haskell installations into
directories named like /usr/local/opt/ghc-7.6.3 and Haskell Platform
installations into directories named like
/usr/local/opt/ghc-7.6.3-2013.2.0.0.  The new Haskell Platform build
system is hard-coded with the ghc-x.y.z-arch convention, however.

I can work with it by using that convention for my Haskell Platform
installations and a different one (such as ghc-x.y.z-arch-min) for my
minimal installations.  I think that it would be preferable, however, to
not force specific installation paths on users.

3. The activate-hs script creates symbolic links as well as registers
packages.  In my environments, I do not create symbolic links, which
alters the system environment.  I want Haskell software installed by the
package manager into /usr to use the packaged Haskell tools (which have
the necessary packages available), not my development installations (which
have minimal global packages since I use sandboxes), but /usr/local/bin is
[generally] before /usr/bin in the system PATH.

My Haskell development environments activate a development installation by
changing the PATH instead.  I think that this method is preferable because
it is environment specific: it only affects a single shell, and it does
not affect the system or other users.  The method also allows easy testing
software with many versions of GHC/HP without updating links.  This method
supersedes the symbolic links anyway, but perhaps the activate-hs script
encourages a bad practice.

Would it be a good idea to make the symbolic link creation optional?
Another option would be to let users link local packages themselves using
GNU Stow.  A benefit of using GNU Stow is that it supports unlinking,
allowing users to easily uninstall linked, local packages.


I recognize that my usage is not mainstream, but I am emailing in hope
that my feedback might be helpful anyway.

Thanks and best regards,

Travis