haskell ghc demodularization?

[Jens-Ulrik Petersen]

Hi,

Recently I have been thinking it would actually be nicer to be able to
parallel install Fedora ghc versions (then one can do things like `cabal
build -w ghc-9.2.1` or get stack to use more system ghc versions etc).

We actually had (the ability to) parallel installs long ago, maybe during
ghc6?
But at the time SIG decided to avoid that to simplify the user experience.

But I want to revisit this now, with a tentative idea to introduce ghc9.2
etc to Rawhide for F36 perhaps.  Having the builds in the main repo is also
more discoverable.
This will also open up the possibility of cabal-install3.6 etc - though
adding ghc9.2.1-network etc is going to be more challenging in terms of
additional maintenance.

Any thoughts on this?
(I would probably "brand" it as parallel ghc installs rather than
"demodularization": actually they are not exclusive, but in the long term
this would probably end the ghc modules effort - even though I have yet to
try the latest modular build iteration.)

Jens

[Fraser Tweedale]

On Wed, Dec 01, 2021 at 10:31:16AM +0800, Jens-Ulrik Petersen wrote:
>  Hi,
>  
>  Recently I have been thinking it would actually be nicer to be able to
>  parallel install Fedora ghc versions (then one can do things like `cabal
>  build -w ghc-9.2.1` or get stack to use more system ghc versions etc).
>  
>  We actually had (the ability to) parallel installs long ago, maybe during
>  ghc6?
>  But at the time SIG decided to avoid that to simplify the user experience.
>  
>  But I want to revisit this now, with a tentative idea to introduce ghc9.2
>  etc to Rawhide for F36 perhaps.  Having the builds in the main repo is also
>  more discoverable.
>  This will also open up the possibility of cabal-install3.6 etc - though
>  adding ghc9.2.1-network etc is going to be more challenging in terms of
>  additional maintenance.
>  
>  Any thoughts on this?
>  (I would probably "brand" it as parallel ghc installs rather than
>  "demodularization": actually they are not exclusive, but in the long term
>  this would probably end the ghc modules effort - even though I have yet to
>  try the latest modular build iteration.)
>  
>  Jens 
Hi Jens,

I'm in favour of the idea.  My only question: will there be a
"default" release that provides the "bare" executables `ghc`,
`cabal`, ...?

Thanks,
Fraser

[Jens-Ulrik Petersen]

On Wed, Dec 1, 2021 at 12:58 PM Fraser Tweedale <ftweedal(a)redhat.com&gt; wrote:

>  I'm in favour of the idea.  My only question: will there be a
>  "default" release that provides the "bare" executables `ghc`,
>  `cabal`, ...? 

Right, good point, Fraser - I forgot to touch on this.

Ya basically the core "mainline" package experience should be unalterated:
people can continue just to install the plain ghc, cabal-install, and other
Fedora Haskell packages
just like now - the only difference would be you will additionally be able
to install say ghc9.2-9.2.1
(/usr/bin/ghc-9.2.1) and maybe cabal-install3.6
(/usr/bin/cabal-install-3.6) (which would be built with ghc9.2).

The earlier implementation used alternatives to allow setting the default
ghc version.
But I am thinking perhaps we would not do that this time round at the
system level.

I think it makes sense to put this forward as a F36 Change proposal.

Jens

ps Also part of the reasoning is that modules are more complicated to
maintain:
eg they sometimes disappear after branching or rebuild failures and SLA EOL
etc.
And they are kind of all or nothing - a simple bumps forces rebuilding for
all releases etc.
Having versions as normal packages will make maintenance more manageable.
The complexity seems too great for building heavy stacks like Haskell.

[Jens-Ulrik Petersen]

ghc9.2 has been built
<https://koji.fedoraproject.org/koji/buildinfo?buildID=1865330> now for
Rawhide: it should be in the next rawhide compose/push.
Any early testing/feedback would be welcome: I tried out briefly and so far
it seems to work.
Next I will also build it for F35.

Also next is ghc9.0 at least for F35.
It is still unclear whether ghc-9.0 will be in F36 or not; though the clock
is ticking quickly.
And technically there is no problem with have both ghcX.Y and ghc-X.Y.Z in
F36 say:
in fact it seems inevitable in the future, as we move through major version
upgrades.
Also ghc8.10 (with 8.10.7), which will allow building ghc9.2 for F34.
It is probably more consistent to build ghcX.Y regardless for all releases
anyway.

As for dependencies: I pushed ghc-rpm-macros-2.3.0
<https://koji.fedoraproject.org/koji/buildinfo?buildID=1864914> to Rawhide -
currently ghc and ghcX.Y packages get different meta deps.
Specifically 'ghc-devel(pkg-id)' vs 'ghc-VERSION-devel(pkg-id)'.
But in the future I am thinking of switching ghc to 'ghc-VERSION-devel(pkg-id)'
-
hopefully that would not lead to resolver ambiguity.

I would like to add cabal-install3.4 and cabal-install3.6 too:
that could be done either with ghcX.Y-PKG or probably bundling the deps.

I also expect to do ghcX.Y for epel9 and epel8.

A Fedora Change will also be forthcoming later this month.

Thanks and let me know if you have any questions or more thoughts on this.

Jens

[Jens-Ulrik Petersen]

I submitted the change as:
https://fedoraproject.org/wiki/Changes/GHC_parallel_version_installs
If you have any questions and feedback that would be welcome.

Thanks, Jens