Re: Dynamic libraries by default and GHC 7.8
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.
Reply to: