Alpine linux version?

[joelmccracken]

I have been working on an image that uses Alpine, and I was wondering if i submitted a PR, it would be welcome. Of course I will change it however it needs to meet standards, I just want to know before I do the work to make it.

[psftw]

Honestly, you would have a big uphill battle to convince me it is worth doing. Unless a musl-based GHC is in the works and makes it into tier2 status (per https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms ), I don't think supporting Alpine is going to happen.

[joelmccracken]

I see. Well, since I wrote this, I made the one we need, so I'll just put the dockerfile we ended up using here and close the issue:

FROM alpine:3.12

ARG STACK_ALPINE_VERSION=2.3.1

RUN apk add --no-cache \
        alpine-sdk \
        ca-certificates \
        ghc \
        zlib-dev \
        bash

RUN curl -sSfL https://github.com/commercialhaskell/stack/releases/download/v${STACK_ALPINE_VERSION}/stack-${STACK_ALPINE_VERSION}-linux-x86_64-static.tar.gz \
    | tar --wildcards -C /usr/local/bin --strip-components=1 -xzvf - '*/stack' && chmod 755 /usr/local/bin/stack && \
    stack config set system-ghc --global true

Thanks!

[utdemir]

I think there has been some developments in this regard, so I would like to ask for re-opening the issue.

I've been maintaining utdemir/ghc-musl for a while. It used to be finnicky to get a GHC with Alpine when the project was using Nix. However, since I have migrated it to use ghcup, it has been pretty smooth sailing.

My project has a few differences:

• I can see that the images compile the GHC themselves, but I've been using official bindists fetched & installed by ghcup.
• It is using a tool called earthly to orchestrate the image builds.
• It has two test cases to ensure that they can be used with cabal-install and stack.

Among those differences:

• I think using ghcup was a good choice, since I do not have to duplicate the effort of compiling GHC
• The earthly use can be replaced by some Dockerfiles and shell scripts.

If you are happy with it, I would be keen to help adding ghcup-powered Alpine/musl images to this repository.

[AlistairB]

(Er I wrote a comment then realised it was wrong.. Looks like ghcup is using the official bindists for alpine.)

👋 Happy to reopen.

Do you know how well supported the alpine ghc release is? I note that there are official bindists for it. My inclination would be to support it if it has no major caveats compared to debian. ie. I think if users get it from the official images they will expect it to just work ™️

In terms of a solution. #46 (comment) is one such example. Although, we considered using ghcup in #45 but ultimately chose direct installation. I wonder if ghcup is doing more heavy lifting on alpine? My initial inclination would be to remain consistent and install ghc directly again.

[utdemir]

Do you know how well supported the alpine ghc release is?

So, I've been using ghc-musl for a while, and it seems to work. I'm not developing on it, so I do not know how well the tooling works, but simply running cabal build inside provides a working executable.

There are some rough edges, as some libraries does not like static linking (utdemir/ghc-musl#14, utdemir/ghc-musl#15). But these issues are not specific to GHC, and more about the platform.

I wonder if ghcup is doing more heavy lifting on alpine? My initial inclination would be to remain consistent and install ghc directly again.

I do not know, off the top of my head I do not think ghcup is doing anything special on Alpine than picking up the correct bindist. I used ghcup because only because it was easier. I think you've summarized pros and cons quite well on #45, so I do not have much to add :).

I agree that consistency is important, so I also do not think it's worth introducing ghcup just for Alpine if there is no major advantage. Although, simply because I had such a nice experience with ghcup, I think maintaining this project would become a bit easier if it was using ghcup; but that's just my personal opinion.

[AlistairB]

I love ghcup too :) We might get there, but for now have not seen a clear benefit. Will probably revisit when considering windows support.

Anyway, you are welcome to create a PR with what you are thinking if that works.

[AlistairB]

I'm going to tackle this next.

[benz0li]

See https://gitlab.b-data.ch/ghc/ghc-musl/container_registry for multi-arch (linux/amd64, linux/arm64/v8) GHC docker images based on Alpine Linux; stack not included.

Using https://gitlab.alpinelinux.org/odidev/ghc-bootstrap-aarch64 (GHC 8.8.3) as bootstrap, I have been able to continuously update to the latest version of GHC (currently 9.2.1).

[AlistairB]

Thanks for the info @benz0li ! This will definitely prove useful to better understand the required alpine dependencies.

Although, I think the goal for the official images should be to house the official releases in Docker with minimal modification. Those images look to be more custom builds from source.

One downside of using the official releases is that they target 3.12 and at least 9.2.1 will not work in 3.14. I think I'd like to better understand the long term plan for supporting alpine from the GHC developers and when we can expect newer alpine versions to be supported.

Anyway, for now I need to explore more using the official releases but I guess at this stage all we can do is only support alpine 3.12 and I'm not sure how useful that would be.

[AlistairB]

Ah hmm, looks like https://gitlab.haskell.org/ghc/ghc/-/issues/20266 is the 9.2.1 issue. Perhaps with this resolved it may just work on newer alpine releases. The convention of other official images seems to be to support the last to stable alpine releases which is currently 3.14 + 3.15. This should be the goal for these images as well I think.

[benz0li]

[...] Those images look to be more custom builds from source.

One downside of using the official releases is that they target 3.12 and at least 9.2.1 will not work in 3.14. [...]

As there are no official releases for alpine aarch64 (linux/arm64/v8), those must be custom built from source.

ℹ️ The custom built registry.gitlab.b-data.ch/ghc/ghc4pandoc:8.10.4 is used to build the amd64 and arm64 binary releases of pandoc.

[benz0li]

Ah hmm, looks like https://gitlab.haskell.org/ghc/ghc/-/issues/20266 is the 9.2.1 issue. Perhaps with this resolved it may just work on newer alpine releases. [...]

IMHO the source distribution of GHC 9.2.1 is broken. There are some fundamental issues to be resolved for the next release.

GHC 9.0.x builds fine on alpine 3.15 and could be used to build pandoc. GHC 9.2.1 does build, too, but fails to build pandoc.

[AlistairB]

I have something that works ok in #60 for 9.0. My inclination is to:

• Wait for 9.2.2.
• Drop support for 8.10 line entirely (as in no more updates). There are some quirks with the 8.10 alpine release that are proving challenging and we are just about to drop 8.10 from further updates anyway.
• Release alpine for 9.0.2 and 9.2.2
• This would be for amd64 only until ghc releases includes alpine arm64.

[benz0li]

@AlistairB FYI https://gitlab.haskell.org/ghc/ghc/-/issues/23482

[benz0li]

As of 2023‑08‑12, my GHC musl images (versions 9.2.8, 9.4.6, 9.6.2 and later) also include the Haskell Tool Stack (Stack).

ℹ️ See https://github.com/benz0li/ghc-musl for further information.

[benz0li]

The GHC musl repository also provides general purpose Dev Containers:

ℹ️ See GHC musl: Dev Containers for further information.

Cross reference: benz0li/ghc-musl#5 (comment)