Haskell executables dynamic vs static linking

[Jens Petersen]

For a long time I was quite "proud" that Fedora Haskell
is using dynamic Haskell linking on primary intel architectures
(ghc-7.8 should support shared libs also on ARM,
but it and cabal 1.18 still default to static linking.)
But of course there are pros and cons for dynamic linking
against Haskell libraries.

pros:
- smaller lighter executables
- enforces rebuilding of reverse deps
  (though this can also be a cons)
- makes use of shared libs to share Haskell object code in memory
- faster linking

cons:
- harder to deploy
- less portable
- dynamically linked tools makes testing/building (for) newer ghc harder

Today I decided to make hscolour statically linked against
Haskell libs in Rawhide.  This will make bootstrapping ghc-7.8.1
or snapshots easier for example, or building ghc rpms for any other version. [1]

I think this is less problematic anyway for BinLib packages
like hscolour, since ghc-hscolour will pick up  any potential
dependency breakage anyway.

I would like to have a static executable for cabal-install too.
Maybe a cleaner alternative is to provide both
a dynamic and a static subpackage, but I am not sure yet
on the best way to do that.  Using alternatives might
be the only realistic way currently perhaps?

Should we do that for more executables packages?

Currently in Fedora because cabal-install is dynamically linked
it is some work to build cabal-install for a new ghc version
which makes testing newer ghc harder.  If we had a statically
linked cabal-install package we could just use it with
any (recent) version of ghc... ie it would be more portable.

Any thoughts or opinions on this?

AFAIK Fedora is the only big distro that packages executables
dynamically linked to Haskell libraries.

Jens

[1] Actually I wish hscolour was just included in ghc.
    It would make life easier.  And likewise cabal-install actually.