Hi, not sure why this mail didn't read my inbox...
Tristan kindly pointed it out to me today.
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.
TBH I am not entirely convinced modules are ideal for Haskell, but it is there is now.
It does have one advantage that it allows canonical installation of a different version of
a package without any packaging tweaks or hacks though.
Perhaps that is what you mean. :)
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.
So err, why not use the modules? :)
I am not clear on your objection to using modules.
It seems to me the ghc:8.10 module already does exactly what you want.
What do you need from ghc-8.10 btw?
Personally I have found ghc-8.6.5 is still fine for me and I can use stack if I need a
newer or older ghc.
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.
No that is not the case - I am tracking Stackage LTS releases.
Fedora 32 is based on LTS 14 (LTS 15 was a little late to make the last release).
Fedora 33 will hopefully rebase to LTS 15 or 16 with ghc-8.8.3.
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.
Are you proposing we deal with Haskell packages like Fedora Rust?
ie only ship sources?
2. Do the built binaries behave as expected?
I am not sure of your point here: your local build is basically equivalent to the module
build.
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?
I think I answered this above - I am tracking Stackage LTS, and it lags behind ghc major
releases.
Even today Stackage Nightly is still on ghc-8.8.3.
Just to clarify this isn't just only about ghc - it is about the ~500 haskell packages
we have in Fedora.
We also have stack now in Fedora, though it is not the latest version (like
cabal-install).
It goes without saying, I am very grateful to everything Jens has
done and
does for this SIG.
Thank you I appreciate your words.
If you have more questions, do ask.
Jens