Problems with Haskell Platform

I seem to be in some sort package dependency hell (which I thought the Haskell Platform did away with). I install ghc using my package manager (I'm on opensuse).
dom1@fourier:~> ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.1 dom1@fourier:~> cabal --version cabal-install version 0.8.2 using version 1.8.0.4 of the Cabal library dom1@fourier:~> cabal update Downloading the latest package list from hackage.haskell.org But
dom1@fourier:~> cabal upgrade cabal-install Resolving dependencies... Downloading HTTP-4000.0.9... Configuring HTTP-4000.0.9... Preprocessing library HTTP-4000.0.9... Building HTTP-4000.0.9...
Network/StreamSocket.hs:30:7: Could not find module `Network.Socket': There are files missing in the `network-2.2.1.7' package, try running 'ghc-pkg check'. Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: HTTP-4000.0.9 failed during the building phase. The exception was: ExitFailure 1 cabal-install-0.8.2 depends on HTTP-4000.0.9 which failed to install. And trying to install the Haskell Platform via http://hackage.haskell.org/platform/2010.1.0.0/cabal/haskell-platform-2010.1...
dom1@fourier:~> cabal install Resolving dependencies... cabal: dependencies conflict: ghc-6.12.1 requires directory ==1.0.1.1 however directory-1.0.1.1 was excluded because ghc-6.12.1 requires directory ==1.0.1.0 Which is somewhat baffling.
So I uninstalled ghc via the package manager and downloaded the linux binaries at http://haskell.org/ghc/dist/6.12.1/ghc-6.12.1-i386-unknown-linux-n.tar.bz2 But sadly
dom1@fourier:~/Downloads/ghc-6.12.1> ./configure checking for path to top of build tree... ./configure: line 1687: utils/ghc-pwd/ghc-pwd: cannot execute binary file configure: error: cannot determine current directory And indeed it is true
dom1@fourier:~/Downloads/ghc-6.12.1> utils/ghc-pwd/ghc-pwd bash: utils/ghc-pwd/ghc-pwd: cannot execute binary file I'm not sure where to go from here. I think my options are a) build ghc from source or b) find the source for ghc-pwd and compile it and then try configure again.
Any help would be appreciated. Dominic.

Dominic Steintiz wrote:
I seem to be in some sort package dependency hell (which I thought the Haskell Platform did away with). I install ghc using my package manager (I'm on opensuse)... But
dom1@fourier:~> cabal upgrade cabal-install
A while back I had a similar problem. I was instructed by the Cabal cabal never to use "cabal upgrade", it's broken. Use "cabal install --reinstall" instead. Hope this helps, Yitz

Yitzchak Gale wrote:
Dominic Steintiz wrote:
I seem to be in some sort package dependency hell (which I thought the Haskell Platform did away with). I install ghc using my package manager (I'm on opensuse)... But
dom1@fourier:~> cabal upgrade cabal-install
A while back I had a similar problem. I was instructed by the Cabal cabal never to use "cabal upgrade", it's broken. Use "cabal install --reinstall" instead.
Hope this helps, Yitz
Hi Yitz, Thanks for this. It turned out that there were some old files in /usr/lib/ghc-6.12.1/package.conf.d/* which were confusing ghc-pkg and cabal. I deleted these and re-installed ghc via the package manager and I am now back working (although not on the Haskell Platform afaik). All I had wanted to do was install the "statistics" package and 3 hours later I had ;-) Dominic.

Dominic Steintiz wrote:
I seem to be in some sort package dependency hell (which I thought the Haskell Platform did away with).
I install ghc using my package manager (I'm on opensuse).
I was just thinking, interactions between Cabal and the distribution package manager could get worse, as shared Haskell libraries become more common. Suppose a distribution ships a package 'foo', but not a package 'bar' which depends on it. The 'foo' package includes shared libraries. The user now installs 'bar' using Cabal. This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager. If 'foo' is built as a shared library, programs built by the user will not work for anyone else. Other users will have the distribution's build of 'foo' rather than Cabal's build. If 'foo' is built statically, it's not quite so bad, but the user will not get the benefits that could come from using shared libraries. Pete

On 31 May 2010 20:14, Pete Chown <1@234.cx> wrote:
I was just thinking, interactions between Cabal and the distribution package manager could get worse, as shared Haskell libraries become more common. Suppose a distribution ships a package 'foo', but not a package 'bar' which depends on it. The 'foo' package includes shared libraries. The user now installs 'bar' using Cabal. This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager.
Why won't it? This, of course, depends on how the distribution ships `foo' in regards to static/shared libraries and what the user's options to Cabal/cabal-install are. In Gentoo, for example, we at the moment only build static libraries, mainly because there has been no pressing need/request for shared libraries; however it would definitely be possible to add support for them (might be difficult dependency-wise if shared library support it optional, but this is also a problem we haven't resolved yet for profiling libraries).
If 'foo' is built as a shared library, programs built by the user will not work for anyone else. Other users will have the distribution's build of 'foo' rather than Cabal's build. If 'foo' is built statically, it's not quite so bad, but the user will not get the benefits that could come from using shared libraries.
In general, even if some application is built statically then it won't work on other machines due to different C library versions (GMP, etc.), so I don't think this is such a big deal. Of course, the big thing here is whether Linux distributions, etc. should ship static or shared libraries by default. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Ivan Miljenovic wrote:
Pete Chown <1@234.cx> wrote:
... This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager.
Why won't it? This, of course, depends on how the distribution ships `foo' in regards to static/shared libraries and what the user's options to Cabal/cabal-install are.
Is there a way of making Cabal install dependencies using the system package manager, then? For example, I might ask Cabal to install package A. Package A depends on B and C. A package for B can be downloaded through APT, but there are no APT-installable candidates for A and C. Are you saying that Cabal can download and install B using APT, then download A and C from Hackage?
In general, even if some application is built statically then it won't work on other machines due to different C library versions (GMP, etc.), so I don't think this is such a big deal.
Your program should run on other machines that use the same Linux distribution, though. The problem is that this won't happen if Cabal ends up building its own shared libraries. For simplicity, let's have a new example... The user asks Cabal to install package X, so Cabal goes to Hackage and gets the latest version, 1.2.3.5. It builds shared libraries from it. Meanwhile, the distribution actually packaged X version 1.2.3.4. The user's programs could have been linked against 1.2.3.4, and then they would have run on all systems using that distribution. As it is, the programs only work on the user's own machine, because that's the only machine with the 1.2.3.5 shared library. One option is to stop Cabal building shared libraries. That would avoid the worst of these problems, but it would still be sub-optimal. The user might want to link against shared libraries, but he won't have the chance, because he installed X from the wrong place. (I believe current versions of ghc insist on linking entirely dynamically or entirely statically. This makes the situation worse, because the lack of a shared library for X prevents the use of shared libraries for anything else.)
Of course, the big thing here is whether Linux distributions, etc. should ship static or shared libraries by default.
With other languages they tend to ship both, and give the user the choice, I suppose. Pete

Pete Chown <1@234.cx> writes:
Ivan Miljenovic wrote:
Pete Chown <1@234.cx> wrote:
... This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager.
Why won't it? This, of course, depends on how the distribution ships `foo' in regards to static/shared libraries and what the user's options to Cabal/cabal-install are.
Is there a way of making Cabal install dependencies using the system package manager, then?
For example, I might ask Cabal to install package A. Package A depends on B and C. A package for B can be downloaded through APT, but there are no APT-installable candidates for A and C. Are you saying that Cabal can download and install B using APT, then download A and C from Hackage?
If you mean cabal-install, then no, there's no integration on either side.
In general, even if some application is built statically then it won't work on other machines due to different C library versions (GMP, etc.), so I don't think this is such a big deal.
Your program should run on other machines that use the same Linux distribution, though. The problem is that this won't happen if Cabal ends up building its own shared libraries. For simplicity, let's have a new example... The user asks Cabal to install package X, so Cabal goes to Hackage and gets the latest version, 1.2.3.5. It builds shared libraries from it. Meanwhile, the distribution actually packaged X version 1.2.3.4. The user's programs could have been linked against 1.2.3.4, and then they would have run on all systems using that distribution. As it is, the programs only work on the user's own machine, because that's the only machine with the 1.2.3.5 shared library.
This is exactly the same with C programs.
One option is to stop Cabal building shared libraries. That would avoid the worst of these problems, but it would still be sub-optimal. The user might want to link against shared libraries, but he won't have the chance, because he installed X from the wrong place.
(I believe current versions of ghc insist on linking entirely dynamically or entirely statically. This makes the situation worse, because the lack of a shared library for X prevents the use of shared libraries for anything else.)
No, 6.12 defaults to statically but allows dynamic linking as well.
Of course, the big thing here is whether Linux distributions, etc. should ship static or shared libraries by default.
With other languages they tend to ship both, and give the user the choice, I suppose.
Really? For C, Gentoo ships very few which either default or have the option of static libraries, and I assume the same is true for binary distributions. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Wed, Jun 2, 2010 at 12:37 PM, Ivan Lazar Miljenovic
Is there a way of making Cabal install dependencies using the system package manager, then?
For example, I might ask Cabal to install package A. Package A depends on B and C. A package for B can be downloaded through APT, but there are no APT-installable candidates for A and C. Are you saying that Cabal can download and install B using APT, then download A and C from Hackage?
If you mean cabal-install, then no, there's no integration on either side.
It's worth noting, though, that cabal-install doesn't track installed packages itself, GHC does. So if you install a library from APT and it writes to the package.conf correctly, cabal-install will be able to find it.

On 3 June 2010 00:37, Ben Millwood
It's worth noting, though, that cabal-install doesn't track installed packages itself, GHC does.
And this is why cabal-install can't tell you when there are new versions of executable-only packages (e.g. happy) available: it doesn't even know that happy is installed let alone what version is installed. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Ivan Lazar Miljenovic wrote:
Pete Chown <1@234.cx> writes:
Is there a way of making Cabal install dependencies using the system package manager, then?
If you mean cabal-install, then no, there's no integration on either side.
That's what I thought. As a result of this, you may find that you end up creating private builds of packages which are shipped by your distribution. You ask Cabal to install a package, which is not shipped by your distribution. Cabal will then build that package's dependencies, *even if* those dependencies should really be installed using your distribution's package manager.
This is exactly the same with C programs.
Yes and no. If I download the source of a C library and build my own shared libraries, my programs might not work on machines where the distribution's version of that library is in use. The particular problem in the Haskell world, though, is that Cabal will create this situation by default.
(I believe current versions of ghc insist on linking entirely dynamically or entirely statically. This makes the situation worse, because the lack of a shared library for X prevents the use of shared libraries for anything else.)
No, 6.12 defaults to statically but allows dynamic linking as well.
That's not what I meant. What I meant is that you can't link against some Haskell libraries statically, and some dynamically. When linking C this isn't a problem. If you don't have a shared version of a particular library, gcc will pick the static version instead. You can even choose static or dynamic for each individual library: $ gcc foo.c -o foo -lz $ ldd foo linux-gate.so.1 => (0x00d0b000) libz.so.1 => /lib/libz.so.1 (0x00dd5000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00152000) /lib/ld-linux.so.2 (0x00a69000) $ gcc foo.c -o foo -Wl,-Bstatic -lz -Wl,-Bdynamic $ ldd foo linux-gate.so.1 => (0x00918000) libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00db0000) /lib/ld-linux.so.2 (0x002e5000)
Really? For C, Gentoo ships very few which either default or have the option of static libraries, and I assume the same is true for binary distributions.
Sorry I misunderstood what you were saying; you're right. I'm not familiar with Gentoo, but on Ubuntu virtually everything defaults to shared libraries. You can choose static if you really want it, though, as in the example above. Pete

On 31 May 2010 20:14, Pete Chown <1@234.cx> wrote:
I was just thinking, interactions between Cabal and the distribution package manager could get worse, as shared Haskell libraries become more common. Suppose a distribution ships a package 'foo', but not a package 'bar' which depends on it. The 'foo' package includes shared libraries. The user now installs 'bar' using Cabal. This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager.
This is a good valid point and one I have been worrying about myself sometimes. I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run "yum install ghc-DEPENDENCY-devel" and before returning to run "cabal install" again. It would be nice to automate this in some way - cabal-install plugins, anyone?? Jens

On 4 June 2010 10:27, Jens Petersen
On 31 May 2010 20:14, Pete Chown <1@234.cx> wrote:
I was just thinking, interactions between Cabal and the distribution package manager could get worse, as shared Haskell libraries become more common. Suppose a distribution ships a package 'foo', but not a package 'bar' which depends on it. The 'foo' package includes shared libraries. The user now installs 'bar' using Cabal. This causes Cabal to install 'foo' (because it is a dependency) and it won't use the distribution's package manager.
This is a good valid point and one I have been worrying about myself sometimes.
I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run "yum install ghc-DEPENDENCY-devel" and before returning to run "cabal install" again.
It would be nice to automate this in some way - cabal-install plugins, anyone??
How difficult is it just to create an RPM for yourself and then put it up in some repository for other people to use? I never use cabal-install to install packages at home (with the exception of testing versions of libraries I'm writing as I'm writing them); instead I create a new ebuild for whatever I want and then put that in the Haskell overlay for Gentoo. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

On Jun 3, 2010, at 20:27 , Jens Petersen wrote:
I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run "yum install ghc-DEPENDENCY-devel" and before returning to run "cabal install" again.
It would be nice to automate this in some way - cabal-install plugins, anyone??
Supposedly a future Cabal extension will be to, instead of installing, write out a package for a vendor packaging system (yum, apt, yast, what have you). Consider contributing to that effort. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

allbery:
On Jun 3, 2010, at 20:27 , Jens Petersen wrote:
I often find myself hitting Ctrl-C at "cabal install HACKAGE" to run "yum install ghc-DEPENDENCY-devel" and before returning to run "cabal install" again.
It would be nice to automate this in some way - cabal-install plugins, anyone??
Supposedly a future Cabal extension will be to, instead of installing, write out a package for a vendor packaging system (yum, apt, yast, what have you). Consider contributing to that effort.
However, we have tools for some distros that do this, and some distro tools support it directly (e.g. "bauerbill --hackage" on Arch Linux knows how to ask cabal2arch to translate the .cabal file). Contribut to yum to allow pulling from hackage, by calling cabal2yum? -- Don

Don Stewart
allbery:
Supposedly a future Cabal extension will be to, instead of installing, write out a package for a vendor packaging system (yum, apt, yast, what have you). Consider contributing to that effort.
However, we have tools for some distros that do this, and some distro tools support it directly (e.g. "bauerbill --hackage" on Arch Linux knows how to ask cabal2arch to translate the .cabal file).
Contribut to yum to allow pulling from hackage, by calling cabal2yum?
In general, I think this is a bad idea. I don't know how it is in Arch, but for Gentoo we need to do a lot of QA'ing to make sure our ebuilds generated with hackport work properly (which is one reason why we don't churn ebuilds out as fast as you generate PKBUILDs). Part of the problem is probably that hackport isn't as polished as cabal2arch, but a few other concerns we need to take care of are: 1) Gentoo has categories for packages; whilst for Haskell stuff we can usually correctly guess dev-haskell/ as the category, there are a few exceptions (e.g. pandoc is in app-text/). This is an even bigger problem when dealing with C deps, etc. 2) Dealing with flags: in most cases, we expose the Cabal flags as USE flags, so we need to take care of getting all those dependencies right. 3) Multiple versions: we have to take care of supporting multiple versions of GHC, as well as different versions of QuickCheck, etc. It doesn't help that due to the limitations of portage, Gentoo ebuilds do not support proper ranged dependencies. However, this is most probably not an issue for most distributions where users get given one version of a specific package and they'll shut up and accept it. 4) It has to build always: related to the above, because we don't provide binaries, we have to ensure that packages are built reliably in a multitude of situations. We recently had the situation where for some reason GHC 6.12.2 would build for someone but then wouldn't actually run; we eventually tracked down the problem to his usage of ccache: as of 6.12.2, the GHC wrapper script hardcodes which C compiler it was built with, and as ccache was only used when building packages the path to the C compiler in the GHC wrapper script was incorrect (so all our hacks to get this new "feature" of GHC working properly when users bootstrap had to be scrapped as they made the situation even worse in this case). Again, these situations are mainly Gentoo-specific due to the unique nature of the distribution (though distributions without categories still have to ensure the Cabal-package-name-to-distribution-package-name mapping is consistent and correct). I would, however, imagine that in general having end users use their package manager attempt to automagically integrate Hackage packages into system packages would be fraught with peril. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

ivan.miljenovic:
Don Stewart
writes: allbery:
Supposedly a future Cabal extension will be to, instead of installing, write out a package for a vendor packaging system (yum, apt, yast, what have you). Consider contributing to that effort.
However, we have tools for some distros that do this, and some distro tools support it directly (e.g. "bauerbill --hackage" on Arch Linux knows how to ask cabal2arch to translate the .cabal file).
Contribut to yum to allow pulling from hackage, by calling cabal2yum?
In general, I think this is a bad idea.
I don't know how it is in Arch, but for Gentoo we need to do a lot of QA'ing to make sure our ebuilds generated with hackport work properly
The ones on Arch "just work". I wonder what we're doing differently. cabal2arch knows a *lot* about Arch's package system.
(which is one reason why we don't churn ebuilds out as fast as you generate PKBUILDs). Part of the problem is probably that hackport isn't as polished as cabal2arch, but a few other concerns we need to take care of are:
-- Don

On Jun 4, 2010, at 06:54 , Ivan Lazar Miljenovic wrote:
Don Stewart
writes: However, we have tools for some distros that do this, and some distro tools support it directly (e.g. "bauerbill --hackage" on Arch Linux knows how to ask cabal2arch to translate the .cabal file).
Contribut to yum to allow pulling from hackage, by calling cabal2yum?
I don't know how it is in Arch, but for Gentoo we need to do a lot of QA'ing to make sure our ebuilds generated with hackport work properly (which is one reason why we don't churn ebuilds out as fast as you generate PKBUILDs). Part of the problem is probably that hackport isn't as polished as cabal2arch, but a few other concerns we need to take care of are:
I don't think anyone just does a conversion and bodges it into the package system, regardless of distribution, package system, or conversion tool. (Or language; you don't do it with gems, eggs, or CPAN packages either.) The tool does the boring part of the job for you, but of course you want to edit metadata, test, etc. before setting it loose. Release engineering is not optional. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

allbery:
On Jun 4, 2010, at 06:54 , Ivan Lazar Miljenovic wrote:
Don Stewart
writes: However, we have tools for some distros that do this, and some distro tools support it directly (e.g. "bauerbill --hackage" on Arch Linux knows how to ask cabal2arch to translate the .cabal file).
Contribut to yum to allow pulling from hackage, by calling cabal2yum?
I don't know how it is in Arch, but for Gentoo we need to do a lot of QA'ing to make sure our ebuilds generated with hackport work properly (which is one reason why we don't churn ebuilds out as fast as you generate PKBUILDs). Part of the problem is probably that hackport isn't as polished as cabal2arch, but a few other concerns we need to take care of are:
I don't think anyone just does a conversion and bodges it into the package system, regardless of distribution, package system, or conversion tool. (Or language; you don't do it with gems, eggs, or CPAN packages either.) The tool does the boring part of the job for you, but of course you want to edit metadata, test, etc. before setting it loose. Release engineering is not optional.
Build/does not build? That can be automated. -- Don

On Jun 4, 2010, at 23:04 , Don Stewart wrote:
Build/does not build? That can be automated.
Automated converters have a certain tendency to become confused and put files in unexpected places, etc. Usually this has less to do with the source than the destination; in particular, RPM sometimes makes some poor assumptions. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

allbery:
On Jun 4, 2010, at 23:04 , Don Stewart wrote:
Build/does not build? That can be automated.
Automated converters have a certain tendency to become confused and put files in unexpected places, etc. Usually this has less to do with the source than the destination; in particular, RPM sometimes makes some poor assumptions.
--
Sounds like a problem with the converters. cabal2arch does no such thing. But we tightly control the environment. -- Don
participants (9)
-
Ben Millwood
-
Brandon S. Allbery KF8NH
-
Dominic Steintiz
-
Don Stewart
-
Ivan Lazar Miljenovic
-
Ivan Miljenovic
-
Jens Petersen
-
Pete Chown
-
Yitzchak Gale