is that possible to customize install path for the build in linux generic category?

[HuStmpHrrr]

i downloaded a generic tarball from haskell.org but it restricts the install path to be root, which is not what i want. I would like the install path resides in my home folder so it's easier for me to keep track of the files and clean up when necessary.

is that possible to do that for future distribution? i well understand that it's hard for the current one to change. or in another way, probably can we ship a built source code instead of executables?

[gbaz]

Related, #212, #146

Here's the relevant script to modify: https://github.com/haskell/haskell-platform/blob/master/hptool/os-extras/posix/installer/install-haskell-platform.sh.mu

Note that the tar splats files out in a whole variety of directories in the system. I suppose one could also just untar it in place, but then where would all the files go? They'd have to be manually placed...

If you figure out the appropriate script for install-haskell-platform-local.sh to splat out the files purely locally but in a usable way (which I imagine would just be an untar into a given target directory, and then some post-hoc either munging of those files, or instructions on how to modify the path, or both), I'd be happy to add it to the repo for future use.

cc: @dagit

[HuStmpHrrr]

i check the activating script. what it does is basically creating soft links. so instead, we can print out some command and ask users to run it. it may include the followings:

echo export PATH=$PATH:$localpath/bin >> ~/.bashrc
echo export MANPATH=$MANPATH:$localpath/share/mann >> ~/.bashrc
sudo ln -s $localpath/share/doc/ghc /usr/share/doc

unfortunately for the third case, a sudo is required. i am not sure if it's possible to add multiple search path of doc folder.

another problem is it's not gonna work if we just modify this simple install script. I tested myself last night by unpacking and copying files and creating soft links around. but still wasn't able to launch ghc. the reason i think is because abs path is compiled into various of places.(if you check ghc the executable, it's a script that launches another executable in /usr/share/haskell-platform/blah). so that's why i suggest whether shipping a compiled version would be possible. I tried last night and I found all files are in the build/ folder, i can't see why it's not possible.

[gbaz]

I agree that its slightly more complicated, but probably not much more.

In particular, there simple script just unpacks the tar and then runs activate-hs from it.

The tar locates all its files into usr/local/haskell/ghc-7.10.3-x86_64/

So we can unpack ghc-7.10.3-x86_64 to the top level instead. Then, the issue is that the activate-hs setup is all about just creating symlinks from the typical location it is in into the typical bindir. Since we want to not do any of that, we can just emit the commands you suggest instead.

This leaves fixing up any paths inside that tree that might expect absolute directories.

This should be able to be accomplished by a global replace on the whole bin dir where each file has the same prefix:

#!/bin/bash
exedir="/usr/local/haskell/ghc-7.10.3-x86_64/lib/ghc-7.10.3/bin"
exeprog="ghc-pkg"
executablename="$exedir/$exeprog"
datadir="/usr/local/haskell/ghc-7.10.3-x86_64/share"
bindir="/usr/local/haskell/ghc-7.10.3-x86_64/bin"
topdir="/usr/local/haskell/ghc-7.10.3-x86_64/lib/ghc-7.10.3"
#!/bin/sh

To fix docs we could do a replace there, or just note that they're broken in this method...

But on the whole, this seems like a tractable problem, and it would be a great feature.

[iainhallam]

This is a bit crazy - I'm going to have to build from source just to put the files in /opt/haskell, unless I can work out all the problems created by these scripts expecting their hard-coded directories.

Can't the scripts in the bin directory work out where they're being run from and use that location instead of relying on hard coded paths?

If not, can the installer generate these files with the correct prefix?

[gbaz]

The scripts in the bin directory are not generated by the platform, but by ghc. They also are relocatable by design -- it is the things they point to which are not.

[iainhallam]

OK; so what's my best route to getting a haskell-platform installation in /opt/haskell? /usr/local is off limits completely.

[gbaz]

If you're doing it just for you (and e.g. not a labwide project or the like) I'd just install the ghc binary directly (where it lets you configure a target directory): https://www.haskell.org/ghc/download_ghc_8_0_2

Following that you can pull the latest cabal install binary from https://www.haskell.org/cabal/download.html and essentially be good to go.

[iainhallam]

I'm preparing it for systemwide installation on 100 machines! My aim is to get to an installation I can wrap up in RPMs for distribution to the lab.

[gbaz]

Ok, so one approach would be to follow the advice above and build rpms based on that.

Talking with some coworkers who know fedora (which I assume you're using) better than me, their advice is to grab the latest ghc and cabal-install spec file (or files) from fedora.org, change the paths, and build rpms based on that. (i.e. from https://src.fedoraproject.org/cgit/rpms/ghc.git/tree/ghc.spec)

[iainhallam]

Sorry - I should have clarified I'm on CentOS 7. I could try the Fedora 22 version, I suppose.

[sgjanssens]

Following the GitHub link at https://www.haskell.org/platform/linux.html#linux-generic and wondering about the possibility of a local (non-root) installation of the generic 64 bit core binary, I ended up here. I saw the issue is old but open, so I hope my novice comment is still welcome.

It seemed to me that this comment by @gbaz should be close to a work-around for installing the generic platform binaries in a non-root location. So, I tried to do it manually. After unpacking in $HOME, I set a variable $GHC="$HOME/usr/local/haskell/ghc-8.2.2-x86_64". Next, in all shell scripts in the $GHC/bin directory I replaced the hard-coded references by a reference to $GHC.

I also updated $GHC/etc/registrations explicitly with the full new path and successfully ran $GHC/bin/ghc-pkg register --force $GHC/etc/registrations/hscolour-1.24.2. (This is what is normally done last in the $GHC/bin/activate-hs script.)

Now $GHC/bin/ghc --version could be invoked, but $GHC/bin/ghci produced various startup errors, complaining about scope and reporting such things as No module named ‘System.IO’ is imported.. Is the default path indeed hard-coded in the binaries themselves?

For the moment I gave up and I decided to manually install in the default root location. It works fine for the time being, but of course the manpage and doc are missing. In any case, everything is kept inside $/usr/local/haskell/ghc-8.2.2-x86_64 and the rest of /usr remains untouched.