On ubuntu I currently have haskell-platform 2011.2.0.1.2 installed, and I
am currently working on some code where it would be very nice to have
Control.Concurrent.Chan be an instance of Eq. Unfortunately, in
base-4.3.1.0, which is the one I have installed, it is not, but in
base-4.4.0.0 Chan is an instance of Eq.
Would it be possible to update base, maybe by sandboxing it with cabal-dev or any
other method, in a way that would not break too many packages?
No, you should never upgrade base. It's one of the boot packages — the packages that GHC itself needs to build, and ships with — and upgrading them will lead to Very Bad Things™. (Here's a full list of boot packages; everything with a - in the tag column is one. Don't upgrade these!)
Indeed, cabal-install's cabal upgrade feature was removed precisely because it had a nasty tendency to upgrade boot packages.
Not only is it a boot package, but being such core functionality, it's pretty much inherently tied to a specific GHC version. Your best option is to install the corresponding newer version of GHC in a local directory.
Related
I am using debian and the haskell-platform on the system gets really old. So I download the newest haskel-platform binary version and place it under /usr/local/haskell and activate it. Now there're 2 versions of ghc. If I type ghc then the old ghc-7.4 will be used and ghc-7.8.3 will certainly call the new one. But I have trouble with cabal. The new cabal cannot be used because of glibc version. Can I make the old cabal work with the new haskell platform ? If so how can I make it work just like there're two cabals. In the other word, I want the default directory of the cabal working with the old platform to still remain $HOME/.cabal and the cabal working with new platform to become the new directory (actually I don't know where). Can anyone help me to configure it so that I can have two versions of haskell-platform working separately on my Linux.
You can use lots of GHC installations at the same time without problems, but I don't think that's true for multiple Cabal installations. All you need is to use up-to-date Cabal, no need to keep any other versions. See this blog post for how to use multiple GHC's: http://osa1.net/posts/2014-12-09-ghc-cabal-installation-guide.html
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
(Before I start: I'm going to use Cabal for Everything that has Cabal in its name and has something to do with Haskell.)
Having had the usual "you need to update X to install Y, but this will break dependency Z" issue again the other day, I thought I'd just ask: why was Cabal not designed to be a full package manager, especially with the following features:
Versioning: install multiple versions of a package alongside each other, let packages pick the desired dependencies. If no package version is specified, use the latest one available.
Update packages - or better, also install the newest version.
Remove packages
Check package integrity
You see where this list is going. Right now, to me Cabal feels like a somewhat sophisticated build system (try finding out which version of Base your package requires when you want to start using it for the first time), that comes with a half-baked package installer.
So the question again: Why wasn't Cabal made a full-featured build/package system? I'm sure there was some design decision that led to the current state.
(This question was somewhat inspired by a rant on Reddit, but contrary to that guy don't mean to offend anyone by the above.) :-)
Installing multiple versions of the same package works perfectly well right now (try cabal install ansi-terminal-0.5.4 && cabal install ansi-terminal-0.5.5), but installing multiple instances of the same package version doesn't. This is something we'd very much like to support, since that would allow us to implement hermetic builds and solve the "dependency hell" problem, but it's not entirely trivial. There was a GSoC project this year to add support for multiple instances to ghc-pkg and Cabal, but the patches aren't in the mainline yet. Here's a video of the HIW 2012 talk about the project's results, and here's the description of the internal design.
As to your other questions, there actually used to be a cabal upgrade command for installing the latest versions of all currently installed packages, but it was removed since it could break your installation (again, having support for multiple instances of the same package version would fix this). Uninstallation support has been on the wish list for a while now, it's just that no-one had time to implement it yet. I guess that the same goes for digitally-signed packages and HTTPS.
Additionally, if you're interested in seeing some of these features implemented, patches to Cabal are always welcome, and with the move to GitHub it became easier than ever to contribute code (contributing cash is also fine if you can afford it - I think Well-Typed will be very happy to talk to you about this).
Update (September 2016): for an update on the current state of affairs see this post by Edward Z. Yang: cabal new-build is a package manager.
I'm looking to install Hubris for a Ruby-to-Haskell bridge.
Recent install instructions say that I need to enable shared library support in Cabal. Are there reasons why I might not want to do that?
One reason is that when you build binaries using shared Haskell libraries, these are affected by any future breakage of your locally installed Haskell packages. In other words, when you upgrade a library, you will have to either keep the old .so files around or rebuild the program. This is the main reason why Debian is not yet providing -dyn packages for any library besides the set of boot packages.
(The fact that cabal-install does not uninstall stuff helps here a bit, I guess. But nevertheless I prefer not to worry that doing something with cabal-install or in .cabal might break existing programs.
A beginner's Cygwin question here - I'd like to install a newer version of Cygwin (the latest, which is 1.7.9) on a few Windows 2008 Server boxes which currently have rather an old version (1.5.25). I need to do an offline, silent install, and I'm currently deciding whether to do some sort of manually produced list of changed/added/removed files, or just replace the old install with the new. The install is quite big (80 odd megs), so just doing the differences might make sense here. It looks like there is nothing in the way of registry servering or so on required to install Cygwin -you just copy the files somewhere, add it the the path and you're good to go.
One problem, though, is that looking at what's changed between old and new reveals that some of the files the most recent install has used are actually older versions that what we've already got. Ie cygintl-8.dll, envsubst.exe, gettext.exe. Surely you can't mix and match versions?
I'd appreciate it if a more experienced Cygwin user could reply with a few hints as to the best approach here.
There's always an official config.ini file that lists a recommended version of each package, plus often both newer and older versions than the recommended one. When you do an installation with setup.exe, you can elect to use the bleeding edge versions for some or all of the packages. Perhaps your 1.5.25 version was installed with all the bleeding-edge packages, and the 1.7.9 just accepted the defaults. It's not unlikely that some sets of old/current/new packages hadn't changed between those two cygwin versions.
In general, you can mix and match a lot of things, just as you can on Linux. You can't take an old version of the core cygwin1.dll library and expect new packages to run against it; but not all the packages have to be in lockstep.
I have about a few problems with a new install of the Qt SDK. I probably only need advice, but specific answers are also welcome. Before I begin a mini-story, I am running RHEL5 on academic license under VirtualBox on OSX 10.6. Using Qt version 4.5.3. This is my situation...
1.) I couldn't compile because g++ wasn't found. I fixed this by creating a link: g++ -> g++34. This allowed me to compile but it generated more errors at link-time. I had installed the framework in my home directory unintentionally so I uninstalled/reinstalled the entire SDK to /usr/local/qt.
2.) At this point I could compile but the linker complained about a missing freetype package. I had that already installed but wasn't sure why it couldn't be found. So I installed a few packages that I thought might be missing like libqt4-devel and libqt4-devel-debug. I also installed a few other general programming packages for later use.
3.) Somehwere in this process I can no longer run qmake. I ran it before and I have it installed at /usr/local/qt/qt/bin/qmake. I could create a link to it (though I shouldn't have to OR I could ensure that the location was in the PATH var). However, at this point Qt Creator says there's no Qt installation found. I re-pointed it to the installation location (using Tools/Options) but it still won't run qmake or anything else for that matter...
I only need this linux install to compile and test my Qt projects which I am developing in OSX. So my question is, should I just wipe this RHEL install and start over? And if so, should I use something else like Ubuntu? I am having plenty of hassles that I don't want to deal with as is. Note, this project will require good OpenGL support.
Is there a particular reason that you don't simply use the Qt package that's part of RHEL?
If for some reason you need to build your own, you can get all of the build dependancies with:
$ yum install yum-utils
$ yum-builddep <whatever the qt package's name is>
#scotchi is right, and you should try to use the Qt package that comes with your system unless you need a very different version. I don't know what version of Qt comes with RHEL but if its not up-to-date enough for you (and it might not be, see below) then you could consider changing OS versions. I would only do this after trying his suggestion though, because you may be able to get things working without the hassle of a full OS install.
Now, as to why you might want to switch: RHEL is, as its name ("Enterprise Linux") indicates aimed at companies who want to run servers, or large deployments of desktops. It emphasizes stability and reliability over being cutting edge. Fairly often the version of the compiler and development libraries lag a little behind the curve. This is what their clients want: a stable platform they can develop against and run programs on for a period of time, not constantly needing to keep up with the latest changes, and thoroughly tested. But for people doing development at home it may not be necessary to stay that conservative. I don't know if this is for work, school or personal programming, but it sounds to me like you should move to one of the more desktop-oriented distros. Ubuntu is great, as is Fedora. If you prefer a RHEL-like environment, then choose Fedora.