Btw if one really wants to opt out of this for some package, one can add:
%undefine ghc_without_dynamic
near the top of one's spec file, and the executable(s) will be dynamically
linked.
I didn't state this earlier but obviously this just affects packages built
with Cabal.
(I believe the only Fedora package not using Cabal is hedgewars.)
Jens
On Fri, Oct 5, 2018 at 5:51 PM Jens-Ulrik Petersen <petersen(a)redhat.com>
wrote:
Hi, I am pleased to announce there is now a ghc module in
updates-testing-modular for F28 and F29: it provides ghc-8.4.3 (the module
stream is called 8.4). I am planning to add a 8.6 stream too. (The Rawhide
module has not appeared yet - not sure why.)
In conjunction with this, I am planning to disable executable dynamic
linking in fedora Haskell packages to make them portable with modules. For
example currently if one uses the ghc:8.4 module it is not possible to
install any Haskell executable packages (cabal-install, pandoc, hlint,
xmonad, gitit, git-annex, ShellCheck, hledger, cabal-rpm, alex, happy,
etc), which seems not a good thing: more an annoyance not a pleasing thing
for users. So starting in Rawhide I am going to change ghc-rpm-macros to do
static link of executables (as cabal-install also does by default).
Currently the only package with a static executable is hscolour - to reduce
ghc rebase pain, but not having cabal-install and most of the other
packages mentioned available for modules is pretty pointless really. I
believe Rust and golang executable packages don't use dynamic linking
either (in fact they don't even ship static library;). So anyway I feel
this not so unreasonable approach and will cause less pain when updating
ghc. Note that for executable packages that include a library there will
still be a dynamic shared library produced, the executable will be
statically linked to Haskell libraries).
Jens
--
Jens Petersen
Associate Manager
i18n Software Engineering
Emerging Platform Group
Platform Engineering
Osaka, Japan