Would it be possible to have recent GHCs in non-modular repositories?
by hekkaidekapus
Greetings everyone,
Let me start with a probably wrong statement: it seems that the Modularity
project allows for packaging and installing many major releases for the same
package. I gather that is a great upside for packagers like Jens, especially
in face of the way Haskell projects manage dependencies.
People who are not really into Modularity can disable the relevant
repositories. That is where begin my troubles — because I am not a Modularity
user. I would like to install a packaged GHC and its its dependencies, and
only that; for any other Haskell package, I can do the build myself. The issue
is that Fedora non-modular repositories ship an old GHC, namely version
GHC-8.6.5. The modular repositories, however, are very up-to-date.
Considering the staggering efforts Jens puts into maintaining a large scale of
Haskell packages, I first thought he downright gave up on packaging non-
modular GHC due to intractable reasons; so, I embarked on a journey of
building stuff to see where things might break.
But, I have not seen anything break (yet?). If I download the SRPMs Jens makes
for modular repositories, they build fine as ursine packages, and I guess that
is not surprising. The apparent downside is using the --allowerasing option
when dnf-installing them; as I wrote above, that is not an issue for the use
case I outlined: all non-boot packages can be built on-demand according to the
local application settings; IMHO avoiding global package databases should be
an uncontroversial practice.
So, what have I got? Let’s see:
1. Were the RPMs really built inside Fedora?
#Yes, a)
rpm --query --list ghc-compiler-8.10.1-93.fc32.x86_64.rpm
# /usr/bin/ghc
# …
# /usr/lib64/ghc-8.10.1/bin/ghc
# …
#Yes, b)
annocheck --disable-hardened --enable-notes /usr/lib64/ghc-8.10.1/bin/ghc
# annocheck: Version 9.21.
# Notes: Range: 0x431db8 .. 0x5634b5.
# [O] Version: 3a1
# Notes: Range: 0x431fc0 .. 0x431fc5.
# [O] Version: 3p906
# [O] Stack Protection: None
# [O] Tool: annobin gcc 10.0.1 20200311
# [O] Tool: running gcc 10.0.1 20200311
# [O] ABI: c0013
# [O] PIC: -fpie
# [O] Short Enums: Not Used
# [O] FORTIFY: not detected
# [O] GLIBCXX_ASSERTIONS: Defined
# [O] Optimization: -O2
# [O] Control Flow Protection: Full
# [O] Omit Frame Pointer: Yes
# [O] Stack Clash Protection: Enabled
# [O] Stack Realign: Not enabled
# Notes: Range: 0x431fc0 .. 0x5634a5.
# [O] Version: 3a1b)
2. Do the built binaries behave as expected?
#Yes:
λ cat > hello.hs << EOF
main = putStrLn "Hello, Haskell SIG!\n"
EOF
λ /usr/bin/ghc hello.hs
[1 of 1] Compiling Main ( hello.hs, hello.o )
Linking hello ...
So, I have a couple of questions: What are the reasons behind letting
GHC-8.6.5 linger in non-modular repositories whereas a fresh compiler could
take its place? Is there anything third parties could do to alleviate the
burden Jens has certainly to shoulder? Would be there a way to avoid non-
modular users having to build GHC from sources every time there is a new
release?
It goes without saying, I am very grateful to everything Jens has done and
does for this SIG.
Regards,
h.
3 years, 9 months
ghc-8.8 and lts-16 for F33
by Jens-Ulrik Petersen
Hi,
I have started work on updating our Haskell packages for ghc-8.8.3 and
Stackage LTS 16 (which was just recently released). Also a lot of fixes and
improvements to cabal-rpm coming soon in 2.0.6.
Currently I am building all the packages locally to make sure everything
works before proceeding to build in a side tag.
Is someone able to help review ghc-network-bsd, which is needed by quite a
few packages with network-3:
https://bugzilla.redhat.com/show_bug.cgi?id=1849255
Also will be preparing a Self-contained Change page soon.
Jens
3 years, 10 months
