feat: Bump GHC 9.8.4 + add bullseye image for 9.8.4

[Totto16]

Bumping 9.8.2 to 9.8.4.
Adding a bullseye variant of version 9.8.4 based on #134

Stackage LTS 23 released recently, which needs ghc 9.8.4

Info

Download: https://downloads.haskell.org/ghc/9.8.4/
Blog: https://www.haskell.org/ghc/blog/20241202-ghc-9.8.4-released.html

[jhrcek]

Thank you. LGTM

[Totto16]

As far as I can see, the CI failures are not directly related to this PR

[jhrcek]

@Totto16 I'm addressing the CI failures here: #144
Let me merge that first before merging this PR.

However I just realized now that docker-library/official-images (https://github.com/docker-library/official-images/blob/master/library/haskell) no longer accepts buster (debian 10) based images (see #132 (comment)) because buster is past the end of life.

So if you really want an official haskell image with ghc 8.4 support, we'll have to migrate the dockerfiles to be based on bullseye (debian 11) at least. Do you want to take a stab at that? You can find some inspiration in similar PRs where we added bullseye support for ghc 9.6 (#137) and 9.10 (#134). If you don't, I can take a stab at that later this week.

[Totto16]

@Totto16 I'm addressing the CI failures here: #144 Let me merge that first before merging this PR.

Ah I see, 👍🏼

However I just realized now that docker-library/official-images (https://github.com/docker-library/official-images/blob/master/library/haskell) no longer accepts buster (debian 10) based images (see #132 (comment)) because buster is past the end of life.

So if you really want an official haskell image with ghc 8.4 support, we'll have to migrate the dockerfiles to be based on bullseye (debian 11) at least. Do you want to take a stab at that? You can find some inspiration in similar PRs where we added bullseye support for ghc 9.6 (#137) and 9.10 (#134). If you don't, I can take a stab at that later this week.

I can do that. 👍🏼

I don't use debian that much, so I didn't know the newest version was already 12, and 11 isn't even the newest 😓
But the release supports deb11 for both arm64 and x86_64 but deb12 only for x86_64, which is interesting, as deb12 is out since "10 June 2023" and I wonder why there are releases with the EOL distro deb10 and no for the newest one 😓

[Totto16]

As far as I see, the old buster images are still bumped, so that we have e.g. 9.6.6 in all 2 variants of buster and bullseye, so I would say, that the old should also be updated to 9.8.4, so I didn't remove the first commit but add the new images based on bullseye based on the 9.10.1 images

[Totto16]

Should I also bump cabal to 3.12 ?
like you said here
#141 (comment)

[jhrcek]

I would say, that the old should also be updated to 9.8.4, so I didn't remove the first commit but add the new images based on bullseye based on the 9.10.1 images

Adding separate bullseye images (and keeping buster ones around) makes sense to me.
I don't have historical context, but is seems to be precedent in this repo, so let's just carry on with it.

Should I also bump cabal to 3.12 ?

Let's keep the PR focused on ghc 9.8.4 upgrade and let's do cabal 3.12 upgrade separately (because ghc 9.8 should work fine with cabal 3.10 based on its release page)

[develop7]

Should I also bump cabal to 3.12 ?

I second @jhrcek, let's leave it as is for now

[develop7]

LGTM, merging

[georgefst]

This PR means that the image uses a GHC version which isn't yet supported by the Haskell Language Server: haskell/haskell-language-server#4493. I've just been talking to a Haskell newcomer who was pretty frustrated by this after overcoming several other tooling issues. Would it make sense for the images to include HLS, even if it means building from source where no official binaries are available?

[Totto16]

This PR means that the image uses a GHC version which isn't yet supported by the Haskell Language Server: haskell/haskell-language-server#4493. I've just been talking to a Haskell newcomer who was pretty frustrated by this after overcoming several other tooling issues. Would it make sense for the images to include HLS, even if it means building from source where no official binaries are available?

I think that isn't really possible / a good option, as the HLS is not really a part of GHC / Haskell, but an additional tool. While it's unfortunate, that GHC 9.8.4 is not supported by a HLS release, the master branch of HLS supports it, and you can build it manually (Like already described in haskell/haskell-language-server#4493). This is in fact an issue of HLS and not GHC itself. So HLS needs to fix this, not this image / repo.

Interesting side fact, https://hackage.haskell.org/package/ghc has nearly all releases listed, like e.g. 9.6.1 until 9.6.6, but 9.8.4 is also missing.

Something about the 9.8.4 release or people doing releases on Haskell tools might have changed. Keep in mind that most of these tools are maintained by volunteers in their spare time. So while this all is unfortunate, it is how it is 🤷🏼‍♂️

Edit: after reading haskell/haskell-language-server#4493 I just repeated a bunch of stuff from that discussion 😄

This comment haskell/haskell-language-server#4493 (comment) sums it up pretty perfectly.

[georgefst]

I think that isn't really possible / a good option, as the HLS is not really a part of GHC / Haskell, but an additional tool.

Fair enough. I'm mostly going by the fact that it is conventionally included in Nix development shells for Haskell.

Keep in mind that most of these tools are maintained by volunteers in their spare time. So while this all is unfortunate, it is how it is 🤷🏼‍♂️

Edit: after reading haskell/haskell-language-server#4493 I just repeated a bunch of stuff from that discussion 😄

This comment haskell/haskell-language-server#4493 (comment) sums it up pretty perfectly.

Ha, yeah, I totally understand the difficulties and I hope to never sound entitled when asking for things from volunteers! I just like to make sure that I do report issues that might not have been recognised.

[Totto16]

This PR means that the image uses a GHC version which isn't yet supported by the Haskell Language Server: haskell/haskell-language-server#4493. I've just been talking to a Haskell newcomer who was pretty frustrated by this after overcoming several other tooling issues. Would it make sense for the images to include HLS, even if it means building from source where no official binaries are available?

There is an option, that comes to my mind, that would be possible:

Some docker images like e.g. nginx have different tags, with different things installed. There is nginx:<version>-perl and nginx:<version> which have different modules / tools installed. Much similar to haskell:<version> and haskell:<version>-slim .

We could add a tag for e.g. haskell:9.8.4-hls that comes with HLS packaged. (The tag name is just a suggestion atm)

That would make sense to me, but we have to ask the actual maintainers of this repo / image, if that would be a good idea or if they would have other solutions.

[Totto16]

I think that isn't really possible / a good option, as the HLS is not really a part of GHC / Haskell, but an additional tool.

Fair enough. I'm mostly going by the fact that it is conventionally included in Nix development shells for Haskell.

Keep in mind that most of these tools are maintained by volunteers in their spare time. So while this all is unfortunate, it is how it is 🤷🏼‍♂️
Edit: after reading haskell/haskell-language-server#4493 I just repeated a bunch of stuff from that discussion 😄
This comment haskell/haskell-language-server#4493 (comment) sums it up pretty perfectly.

Ha, yeah, I totally understand the difficulties and I hope to never sound entitled when asking for things from volunteers! I just like to make sure that I do report issues that might not have been recognised.

It's late in the day, and I Just realized, that you were the person who commented haskell/haskell-language-server#4493 (comment) 😂 🤦🏼‍♂️

[Totto16]

Ha, yeah, I totally understand the difficulties and I hope to never sound entitled when asking for things from volunteers! I just like to make sure that I do report issues that might not have been recognised.

It is a real issue and it's always good to talk publicly about it, I noticed the issue, and just fixed some local things and things in my CI and never commented anywhere about it. I also assume, that over on https://github.com/haskell/haskell-language-server this problem is known by maintainers, but there are some reason, that it was not fixed / solved in some way.

So finding a solution by all tools and things that depend on each other is a good start.

And raising issues should never be withheld on the fear of being told, that asking would be rude / inappropriate.

OSS as I know it depends on people seeing issues in the tool that they use, raising concerns and eventually also create PRs, that fix that 😄 At least that was also the thing I did in this PR, by bumping GHC to 9.8.4 as I also needed an docker image, that supports https://www.stackage.org/lts-23.8 😄