On Wed, 2012-11-28 at 00:28 +0100, Joachim Breitner wrote:
Am Dienstag, den 27.11.2012, 14:52 +0000 schrieb Ian Lynagh:
The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault
If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions
here comes the obligatory butting in by the Debian Haskell Group:
Given the current sensitivity of the ABI hashes we really do not want to have Programs written in Haskell have a runtime dependency on all the included Haskell libraries. So I believe we should still link Haskell programs statically in Debian.
Hence, Debian will continue to provide its libraries built the static way.
I was so excited for a bit thinking that this would finally mean that Debian would move to a dynamic system. Every haskell binary being 10s of MBs (e.g., pandoc = 25MB executable) makes it look kind of bad.
From our previous discussion on this
http://lists.debian.org/debian-haskell/2010/03/msg00120.html it seemed a big part of the problem is you really need to be able to have multiple versions of the same package installed. At the time, I believe the only way to do this was to include part of the hash in the name, but that meant you had to constantly be creating new packages which Debian didn't make easy. Maybe it is time to explain the problem to the Debian packaging people and see if they have any ideas from their level?
Building them also in the dynamic way for the sake of GHCi users seems possible.
I was left with the impression that we were going to have this back in 2010 just as soon as squeeze got out the door... :) http://lists.debian.org/debian-haskell/2010/03/msg00155.html Cheers! -Tyson PS: Another solution might to move up one level. That is, use the packages in some way other than for actual standard packaging. For example, they could be taken to mean what the user wants built. The installed packages then becomes the roots in a NIX style store. Another example, do something like akmods system under redhat. The package actually builds a new locally generated package that is then installed to get around the can't easily create new package issue.