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