Haskell Platform 2014.2.0.0: Linux installation

[Travis Cardwell]

Hi Mark,

Thank you very much for the quick reply!

On 2014年08月10日 23:56, Mark Lentczner wrote:
> On Sun, Aug 10, 2014 at 8:46 AM, Travis Cardwell wrote:
>> 1. I do not think that installing into /usr/local/haskell is good
>> organization
> 
> It was my pick... and I recognize there is no good, universally accepted
> place, to put such things short of mixing them into the
> /usr/local/{bin,lib,share} trees.

Indeed.  GNU Stow defaults to /usr/local/stow, but I think that
/usr/local/opt would be more apt.  (Apologies for the pun; I could not
help that one!)

>> 2. The new Haskell Platform build
>> system is hard-coded with the ghc-x.y.z-arch convention
> 
> This convention seems to be permeating the Haskell ecosystem. In
> particular, the new cabal layouts use it. I decided to keep it. Including
> the architecture is nice for those developers that want to keep both 32-bit
> and 64-bit installed for testing. The melding of the platform with the ghc
> space was because it really isn't possible to replace one keeping the
> other, and others didn't like the complication of two trees (though that is
> what we have on OS X).

On Linux, my policy is to strictly avoid user-level packages: my ~/.cabal
directory contains neither bin nor lib directories.  A minimal set of
packages (or the Haskell Platform packages) are installed globally, and
everything else is done within sandboxes.  This allows me to test both
types of installations, even when the GHC version and architecture are the
same.

I have software that provides a menu for users to select which [Haskell,
etc.] development environment they would like to use (for the current
shell).  The menu items are the installation directory names.  Until now,
I have used names like "ghc-7.6.3-2013.2.0.0" for Haskell Platform
releases because it clearly shows the Haskell Platform version and GHC
version to users.

I can modify my software to pull the Haskell Platform version number from
the haskell-platform.cabal file, so I can continue to provide the same
functionality.  I just bring up the issue so that it is documented.

>> 3. The activate-hs script creates symbolic links as well as registers
>> packages. ... Would it be a good idea to make the symbolic link creation
>> optional?
> 
> Sure. Pull requests welcome!

I have submitted a pull request that makes this change.

I feel apologetic that my change is so minimal, even though I see other
things that I could help out with.  I am currently at a very stressful
point in my life, but I look forward to contributing further when I get
the time!

>> 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 wouldn't want to rely on that as I don't think one could expect it to be
> in most linux distributions base package set.

GNU Stow is indeed not a standard package, and some other programs do
(optional) linking during installation as well.  (Racket comes to mind.)
My personal opinion is that people who install into /usr/local should
install and use GNU Stow (or XStow) and follow the Unix philosophy of
having separate tools that do specific tasks well. ;)

Speaking of which, I just spotted a bug in the current script:

    symLinkInto "$ghcRoot"/share/man/man1/* "$prefix/share/man/man1"

This line assumes that "$prefix/share/man/man1" already exists, which is
not always true.

Another possible source of issues is conflicting LINK_NAMEs that are not
links.  GNU Stow would abort with an error, allowing the user to clean up
the problem.  Currently, this script would fail.  If the symLink function
were used, then it would remove any conflicting files/directories (which
is probably not a good idea).

As I mentioned in my previous email, I think that linking GHC into
/usr/local is a bad practice.  After sending the email, I realized that I
should have been more specific.  A specific example is XMonad on Debian
Wheezy.  Users who install XMonad through the package manager generally
install the libghc-xmonad-dev package in order to compile their
configuration, and this package brings in many libghc-* package
dependencies.  All of these packages are global, and configuration
compilation is done without a sandbox.  If a user installs Haskell
Platform 2014.2.0.0 and allows it to link into /usr/local/bin, then XMonad
configuration compilation would stop working, as the many dependencies are
not part of the Haskell Platform installation.  The user could fix the
issue by removing /usr/local/bin from the PATH (problematic) or installing
the required packages on top of Haskell Platform (encouraging Cabal Hell).

If you would like to continue linking (in spite of the side effects), then
I would be happy to help fix issues like those I mentioned above, as soon
as I get a chance (which will hopefully be well before the next release).

Cheers,

Travis