Currently, I am using GHC 7.10.1 on my ubuntu 14.04 system, just now I got noticed from mailing list that a new version containing a lot of bug fixes has been released. So I am considering updating my GHC.
I know how to install GHC, however, I have little knowledge about how to deal with packages I have already installed through cabal. It seems that those packages were installed into ~/.cabal, for example, libs were installed into ~/.cabal/lib/x86_64-linux-ghc-7.10.1 and registered in ~/.ghc/x86_64-linux-7.10.1.
The path name(...x86_64-linux-7.10.1...) seems to be suggesting that they could only be used by GHC 7.10.1, so if I want to use a new version GHC and remove the old ghc 7.10.1 from my system, should I clean them up and reinstall those packages?
for example, should I rm -rf ~/.cabal && rm -rf ~/.ghc and reinstall both cabal and GHC? or should I just leave those packages there? if so, would those installed packages get reused by the new GHC?
Yes, you need to reinstall the packages when you update the compiler.
However, if you delete ~/.ghc then that removes the packages from GHC's point of view. You can also delete ~/.cabal and reinstall everything, but binaries in ~/.cabal/bin (including cabal) will usually still work, so often it's easier to keep these and save some time (have a look to see what's there). There might be problems with some - I think some binaries may have the GHC path hard coded internally, so will break, but you can always reinstall them.
~/.cabal/packages contains cached downloads so it's up to you whether you delete that. The data will just be pulled down again next time your run cabal. If in doubt just delete it.
You should delete ~/.cabal/lib which contains the compiled packages and won't be compatible with a different GHC. Likewise for ~/.cabal/share.
Unless you've edited your ~/.cabal/config file by hand and want to keep the changes you can delete that too and a new one will be created.
You don't need to remove anything. If you install GHC 7.10.2 in the same location that you installed GHC 7.10.1, then all the symlinks ghc, ghci, ghc-pkg etc. will be overwritten to point to 7.10.2, but you can still run the versioned programs ghc-7.10.1, ghci-7.10.1, ghc-pkg-7.10.1, etc., or tell cabal to build with a specific compiler with the -w flag. All libraries and library registration information (whether they came with GHC, are installed in the user package database, or are in a sandbox) are (by default) stored under GHC version-specific subdirectories, so different versions of GHC will not interfere with each other.
If you're not running low on disk space I would suggest not removing GHC 7.10.1. After all 7.10.2 was released just yesterday, and if you encounter a strange issue with 7.10.2, it might be worth checking whether 7.10.1 was also affected.
Related
I recently downloaded the Haskell Platform from the Haskell website. Under the suggestion of the newer answers in this, I blindly ran brew install ghc cabal-install and cabal install cabal cabal-install. Did I install two versions of Haskell on my machine? What should I do to fix any problems?
It doesn't necessarily lead to problems to have multiple versions (I think I have three different versions installed). If you need the disk space uninstall one of the two (instructions for the brew one, for the packaged platform it seems you should be able to use the command sudo uninstall-hs but check it yourself first). If you don't mind the lost disk space, you only have to make sure you have your PATH set up correctly, with the directory containing the ghc binary you want to use in your PATH, before the directory of the other one.
Also, cabal install cabal-install (which you might need to run to update cabal) tends to install cabal in a different place than the platform/brew do, so there, again, you need to make sure your PATH is appropriately set. Normally cabal installs executables in ~/.cabal/bin (local installs) or /usr/local/bin (global installs). The directory containing cabal should go before the others, because an old version of cabal might stick around and you want the new one to be found first.
You probably know this but you can use which ghc and which cabal to check the location of the executable actually being used.
To make things even more complicated, lately it's popular to use Stack, which can also install ghc for you (I find this very convenient, everything is kept in a very controlled environment). So depending on your experience/use case this might be worth looking at as well (but if you just want to try Haskell I recommend you stick with the platform or the brew installation).
I have the 3.0.1 version of Alex installed on my /usr/bin. I think the Haskell Platform originally put it there (although I'm not 100% sure...).
Unfortunately, version 3.0.1 is bugged so I need to upgrade it to 3.0.5. I tried using cabal to install the latest version of Alex but cabal install alex-3.0.5 it installed the executable on .cabal/bin over on my home folder instead of on /usr/bin
Do I just manually copy the executable to /usr/bin? (that sound like a lot of trouble to do all the time)
Do I change my PATH environment variable so that .cabal/bin comes before /usr/bin? (I'm afraid that an "ls" executable or similar over on the cabal folder might end up messing up my system)
Or is there a simpler way to go at it in general?
I want to first point out the layout that works well for me, and then suggest how you might proceed in your particular situation.
What works well for me
In general, I think that a better layout is to have the following search path:
directories with important non-Haskell related binaries
directory that cabal install installs to
directory that binaries from the Haskell platform are in
This way, you can use cabal install to update binaries from the Haskell platform, but they cannot accidently shadow some non-Haskell related binary.
(On my Windows machine, this layout is easy to achieve, because the binaries from the Haskell platform are installed in a separate directory by default. So I just manually adapt the search path and that's it. I don't know how to achieve it on other platforms).
Suggestion for your particular situation
In your specific situation with the Haskell platform binaries already installed together with the non-Haskell related binaries, maybe you can use the following layout for the search path:
directory containing links to some of the binaries in 3
directory with important non-Haskell related binaries and Haskell platform binaries
directory that cabal install installs to.
This way, binaries from cabal install cannot accidently shadow the important stuff in 2. But if you decide you want to shadow something form the Haskell platform, you can manually add a link to 1. If it's a soft link, I think you only have to do that once per program name, and then you can call cabal install for that program to update it. You could even look up what executables are bundled with the Haskell platform and do that once and for all.
On second though, putting /.cabal/bin in front of /usr/bin in the PATH is simpler and is what most people do already.
Its also not a big deal since only cabal will put files in .cabal/bin so it should be predictable and with little risk of overwriting stuff.
It's rather nice that ghc-pkg check will list broken packages, and why they are broken. But as far as I know, there is no automated way to take care of those broken packages. What is the recommended way to deal with broken packages? (Preferably not reinstall GHC)
Hopefully, you have been wise enough to not break any in your global package database. Breakage there can easily mean a reinstallation of GHC is necessary. So, let us assume that the breakage is restricted to the user package db (except possibly a package or two in the global shadowed by user packages). If only few packages are broken, you can fix your setup by unregistering the offending packages,
$ ghc-pkg unregister --user borken
that will often complain that unregistering borken will break other packages. Whether you try to unregister those first or unregister borken immediately with --force and deal with the newly broken afterwards is mostly a matter of choice. Make sure that you only unregister packages from the user db. If things aren't too grim, after unregistering a handful of packages, ghc-pkg check will report no more broken packages.
If, on the other hand, a large proportion of packages is broken, it will probably be easier to completely wipe the user db, $ rm -rf ~/.ghc/ghc-version/package.conf.d or the equivalent on other OSs.
Either way, you will have lost packages you still want to use, so you will try to reinstall them without breaking anything anew. Run
$ cabal install world --dry-run
that will try to produce a consistent install plan for all the packages you installed with cabal-install. If it fails to do so, it will print out the reasons, you may then be able to fix the issues by adding constraints to the packages listed in the world file (~/.cabal/world) - for example, although I have no broken packages (according to ghc/ghc-pkg), cabal install world --dry-run told me it could not configure vector-algorithms-0.5.2, which depends on vector >= 0.6 && < 0.8 (I have vector-0.7.1 installed). The reason is that hmatrix-0.12.0.1 requires vector >= 0.8. Replacing the -any "constraint" on hmatrix by a "< 0.12" in the world file produced a clean install-plan.
So, after a bit of fiddling with constraints in the world file, you will get an install plan from cabal. Check whether that would reinstall any packages you already have (installing a newer version is probably okay, reinstalling the same version means trouble). If you're happy with cabal's install-plan, cabal install world and brew a nice pot of tea while GHC is busy. Run ghc-pkg check once more, to verify all is in order.
A piece of generally good advice: If you don't know what installing a package entails, always use --dry-run first.
If you broke your global package database by doing global installs with cabal, the strategy of unregistering offenders may work, but it may also irrevocably break your ghc, that depends on what is broken in which way. If you broke your global db by installing packages from your OS distro, install a fresh GHC, curse the distro-packagers, and try to help them prevent further such events.
A cabal repair command would be very nice, but for the time being, repairing a broken setup is unfortunately much more work.
For some time I've relied on this ghc-pkg-clean script. It removes all broken packages and I reinstall them as needed. For more serious breakage, I use the ghc-pkg-reset script.
Today, though, I found ghc-pkg-autofix, which automates this further - broken packages become unbroken. I don't know what it does, YMMV.
I'm on OSX 10.6 and I have platform 2010.2.0.0 currently. Should I just install 2011.2.0.1 on top or is there an update mechanism that will be smoother?
I've definitely had bumpy upgrade experiences with the Haskell Platform. If you have enough trouble that you just want to wipe the thing and start fresh (you wouldn't be the first!), take a look here:
Everywhere that GHC/Haskell Platform installs
As far as I know there is no update mechanism. And I have never had any trouble with just installing one platform version on top of the other on OSX.
I come from the future (06/2013) and I just had to nuke my entire installation of the haskell platform in order to successfully install a newer. So... there's still no smooth way of upgrading. (At least in OS X)
Whether you need to nuke the existing platform depends on where cabal is configured to install packages.
On Mac OS X, the supplied cabal-install is modified to create a config which separates packages by GHC version. If that's the config you used, you can just install the Haskell Platform on top of the old one.
install-dirs user
prefix: /Users/pgiarrusso/Library/Haskell/$compiler/lib/$pkgid
-- [...]
install-dirs global
prefix: /Library/Haskell/$compiler/lib/$pkgid
Installation-specific binaries, like the ones from gtk2hs-buildtools, are only separated with a configuration like the above. As far as I can tell, at least the actual package register (in ~/.ghc/$GHC_VERSION, used by ghc-pkg and cabal) is instead always per-GHC-version.
The config generated by a vanilla cabal-install (from Hackage) does not take such precautions.
install-dirs user
-- prefix: /Users/pgiarrusso/.cabal
[...]
install-dirs global
-- prefix: /usr/local
If you have such a config, I expect you're going to get trouble unless you remove at least the data in ~/.cabal, and also the binaries in /usr/local from the old Haskell Platform — but don't nuke the whole directory, since /usr/local is often used for installing other software!
The default config is only generated when no config exists, so to update the config you need to move away the existing one.
Over here is the only reason I can find that packages I'm installing using cabal are not being found by GHC:
This happens when you install a package globally, and the previous packages were installed locally. Note that cabal-install install locally by default [...]
Presumably, "local installation" means putting packages in ~/.cabal/. First question: where are global installs?
I've been running cabal using sudo, so I guess that's a global install? The reason I've been doing this is that it complains about permissions when run without sudo, so this contradicts the statement "cabal-install install locally by default". Second question: how do I install locally and how do I install globally?
Trying to fix this mess, I've been randomly using sudo ghc-pkg unregister and randomly removing stuff from ~/.cabal/. Consequently my package tree is broken, probably locally and globally. Third question: How do I start again?
Edit: I'm running Ubuntu 10.10. I installed the Haskell Platform 2011.
Are you using Windows, OS X or some version of Linux? Are you using the Haskell Platform? Have you had a version of ghc or cabal before? For a Linux distribution, subtleties about your package manager may come in, of course. (Traces of an old ghc in particular, and an old ~/.ghc/ directory can be a source of trouble.)
Here are a few elementary thoughts of the type one goes through on #haskell with such problems. (My comprehension is not completely adequate, of course):
The chief question seems to be, Why you were being invited to do what should be local installs with sudo? A global install (cabal install pony --global) would of course require privileges if ghc and its libraries are in /usr/... or some other protected place, but otherwise sudo vs non-sudo is independent of the place of installation. What you do with cabal install pony --user (--user is the default, in theory) should not require superuser authority. (I have sometimes found on OS X that privileges are requested where the gcc needs to be called, but this has usually been due to curiosities about my setup.) But in any case sudo doesn't affect where cabal is putting them: the implicit --user and explicit --global, and more specific incantations for development, do that.
If you do ghc-pkg list, for example, it will divide the packages into the different places they are registered in according to two or more package.conf.d directories it is summarizing. On my laptop at the moment these are
/Users/applicative/.ghc/x86_64-darwin-7.0.3/package.conf.d/...
for the local things in ~/.cabal/lib/... and the protected
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/package.conf.d
for things that were installed globally with the Haskell Platform installer (this location involves some OS X peculiarities, ghc, ghci and so on are in the woods somewhere, but symlinked to /usr/bin). The conf files for different packages tell you exactly where the libraries were installed. So, for example about the sacred base library,
$ cat base-4.3.1.0-f5c465200a37a65ca26c5c6c600f6c76.conf
tells me:
import-dirs:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0
library-dirs:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/base-4.3.1.0
In any case, where does ghc-pkg list say your cabal install-ed packages are going? In the ~/.cabal folder, look at the file config. If you haven't edited it, I think the commented and uncommented lines, if they state a preference, are stating the defaults for installation with --global and --user. In the ~.ghc/ directory check out the subdirectory myghcversion/package.conf.d and see if anything is there, which should be the same as what ghc-pkg tells you. (You might study the options for ghc-pkg in general, eg. ghc-pkg check and ghc-pkg recache, if you haven't. You may have installed something in some odd way.)
If you installed ghc and cabal and co. by installing the Haskell Platform with a binary installer or your package manager, which seems like a good idea, it is also a good idea, I think, to keep the Platform libraries as something sacred, and make sure you never install anything globally from Hackage; among other things this is likely to have you overwriting Platform libraries -- though this doesn't seem the difficulty here: it would be more obvious if it were.