Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install GHC directly #46

Merged
merged 3 commits into from
Oct 7, 2021
Merged

Install GHC directly #46

merged 3 commits into from
Oct 7, 2021

Conversation

AlistairB
Copy link
Contributor

@AlistairB AlistairB commented Sep 12, 2021

Alternative fix for #45 rather than using ghcup

I mostly just copied https://gitlab.b-data.ch/ghc/ghc4pandoc/-/blob/master/8.10.6.Dockerfile 馃槄

Pros

  • Can use gpg to verify the GHC release (ghcup does not currently do this).
  • Avoid multi-stage docker build which apparently is not preferred for official images.
  • Can immediately update to new versions upon release. (Although to be fair ghcup is very prompt adding new releases)

Cons

  • A bit more manual.

GHC GPG key issues

I'm getting some issues with the GHC GPG key. https://gitlab.haskell.org/ghc/ghc/-/issues/20362 Should be pretty straight forward to add the key to keyserver.ubuntu.com which would resolve it.

Cabal

So I have left cabal install 3.4 with the current technique which will need to change. The cabal releases do not contain GPG signatures for the binary tar files. There is SHA256SUMS.sig which can be used to verify the SHA256SUMS, then you could use those sha256 hashes to verify the tar file?

Actually I'm struggling to find the GPG key I need to verify SHA256SUMS.sig . Regardless, I guess ideally gpg signature files are created for the cabal releases? I could ask on the cabal repo for this?

Anyway, I have created haskell/cabal#7639 to get some feedback from Cabal on how best to do this.

Current Preference

Overall I think this is better than the ghcup based solution if we can get a nice solution to the cabal problem.

@hasufell
Copy link
Member

Can directly tweak the GHC install in the future ie. control the聽BuildFlavor聽or whatever.

To control the build flavor you have to compile from source. And ghcup both supports compiling from source and setting the build flavor. So this point is a bit confusing.

@hasufell
Copy link
Member

A bit more manual.

Again, you're missing from the Cons:

  • can't quickly switch into container and install a different GHC/cabal, but instead have to meddle with multi stage docker builds (which are now oddly discouraged) or figure out how to download and install bindists manually

@AlistairB
Copy link
Contributor Author

To control the build flavor you have to compile from source. And ghcup both supports compiling from source and setting the build flavor. So this point is a bit confusing.

My mistake, makes sense. I removed it.

can't quickly switch into container and install a different GHC/cabal, but instead have to meddle with multi stage docker builds (which are now oddly discouraged) or figure out how to download and install bindists manually

Multi-stage builds are discouraged for official docker images, but for not discouraged for general use. I do not see how this relates anyway. You don't need multi-stage to extend a docker image and add in more stuff.

I do not think installing multiple ghc / cabal in a container is a common use case. I think we will have to agree to disagree here.

@hasufell
Copy link
Member

I do not think installing multiple ghc / cabal in a container is a common use case. I think we will have to agree to disagree here.

Sure, I think it's best if ghcup provides its own set of docker images.

@AlistairB
Copy link
Contributor Author

AlistairB commented Sep 12, 2021

@hasufell

Sorry, to be clear I still want @psftw to make the call here re: leaving ghcup in the image if we go for ghcup. I just don't see a point in us rehashing the same arguments in this PR.

Of course you are welcome to make your own docker images. I would still generally be in favor of a haskell:ghcup image if you are interested in creating a separate issue for that.

@hasufell
Copy link
Member

hasufell commented Sep 14, 2021

Can use gpg to verify the GHC release (ghcup does not currently do this).

This isn't strictly true either. Here's an example:

FROM alpine:latest

# install deps needed by GHC
RUN apk add --no-cache \
    curl \
    gcc \
    g++ \
    coreutils \
    binutils \
    binutils-gold \
    gmp \
    ncurses \
    libffi \
    make \
    xz \
    tar \
    perl \
    gnupg

ARG GHCUP_VERSION=0.1.16.2
ARG GHCUP_METADATA_VER=0.0.6
ARG GPG_KEY=7784930957807690A66EBDBE3786C5262ECB4A3F

# install ghcup
RUN gpg --batch --keyserver keys.openpgp.org --recv-keys $GPG_KEY && \
    curl -sSfL -O https://downloads.haskell.org/~ghcup/$GHCUP_VERSION/x86_64-linux-ghcup-$GHCUP_VERSION && \
    curl -sSfL -O https://downloads.haskell.org/~ghcup/$GHCUP_VERSION/SHA256SUMS && \
    curl -sSfL -O https://downloads.haskell.org/~ghcup/$GHCUP_VERSION/SHA256SUMS.sig && \
    gpg --verify SHA256SUMS.sig SHA256SUMS && \
    sha256sum -c --ignore-missing SHA256SUMS && \
    mv x86_64-linux-ghcup-$GHCUP_VERSION /usr/bin/ghcup && \
    chmod +x /usr/bin/ghcup && \
    rm SHA256SUMS*

ENV GHCUP_INSTALL_BASE_PREFIX=/usr/local
ENV PATH=/usr/local/.ghcup/bin:$PATH
ENV GHCUP_METADATA_FILE=ghcup-${GHCUP_METADATA_VER}.yaml
ENV GHCUP_METADATA_URL=https://www.haskell.org/ghcup/data/$GHCUP_METADATA_FILE

RUN mkdir -p "$GHCUP_INSTALL_BASE_PREFIX"/.ghcup/cache && \
    cd "$GHCUP_INSTALL_BASE_PREFIX"/.ghcup/cache && \
    curl -sSfL $GHCUP_METADATA_URL > $GHCUP_METADATA_FILE && \
    curl -sSfL $GHCUP_METADATA_URL.sig > $GHCUP_METADATA_FILE.sig && \
    gpg --verify $GHCUP_METADATA_FILE.sig $GHCUP_METADATA_FILE && \
    ghcup -s file://$(pwd)/$GHCUP_METADATA_FILE install ghc --set 8.10.7 && \
    ghcup -s file://$(pwd)/$GHCUP_METADATA_FILE install cabal latest && \
    ghcup -s file://$(pwd)/$GHCUP_METADATA_FILE install stack latest

@hasufell
Copy link
Member

GPG support in ghcup has landed: https://gitlab.haskell.org/haskell/ghcup-hs/#gpg-verification

Can immediately update to new versions upon release. (Although to be fair ghcup is very prompt adding new releases)

It happens on release day.

Copy link
Contributor

@psftw psftw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other than a nitpick question, this looks good to me.

8.10/buster/Dockerfile Outdated Show resolved Hide resolved
@AlistairB
Copy link
Contributor Author

AlistairB commented Oct 6, 2021

I was thinking about waiting on this cabal issue for upgrading cabal to 3.6, but I think I will just go ahead and do it using option 2 from that issue. I'll make that change as well now.

Bump ghc to 8.10.5. Bump cabal to 3.6.0.0.

Also sha256 verify GHC + stack and other minor clean up.
@AlistairB
Copy link
Contributor Author

AlistairB commented Oct 6, 2021

Thanks @psftw . This should be good for a final review now.

  • I have updated cabal to also direct install version 3.6.0.0
  • Remove 300mb of docs we don't need from ghc.
  • Stack tar also has docs we don't need, so just extract the executable.
  • Other minor cleanup and consistency things.

@psftw psftw merged commit 4181ccd into haskell:master Oct 7, 2021
@AlistairB AlistairB mentioned this pull request Nov 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants