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 _______________________________________________ haskell mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected]
