search

haskell / docker-haskell

MIT License
63 stars 37 forks source link

Update from debian stretch (9) to buster (10) for ghc 8.6, 8.8 #15

Closed AlistairB closed 4 years ago

AlistairB commented 4 years ago

Closes #8

https://downloads.haskell.org/debian/ currently only has cabal version 3.0 in buster, so I thought updating to it for 8.6 was probably worth it (and with cabal 3.0 I think latest stack should work better). Alternatively 8.6 could be left as is on stretch. For this reason I have not touched 8.2, 8.4 which currently use old versions of cabal.

This is something of breaking change if people naively pull the new version. Might be worth some kind of 8.8-buster tag, or 8.8-stretch. This appears to be handled manually? Or is this a change I can make in my PR?

hvr commented 4 years ago

@psftw I'm still a bit confused about whether this is reconcilable with the conservative goals you stated in https://github.com/haskell/docker-haskell/pull/6#issuecomment-556492137 which back then significantly dampened Oleg's motivation/enthusiasm back then.

I've been meaning to catch you on IRC but I'm not sure when you're online.

psftw commented 4 years ago

@hvr will get back on IRC and try to catch you soon. My only concerns are that we don't break people, and that we keep the support matrix focused with a good testing/validation setup. I don't think it is worth it to update the 8.6.5 tag any further if we can avoid it, but I wouldn't be opposed to adding a buster variant and bumping the Stack/Cabal versions if we are sure this is actually a good idea. I don't recall the reason why these were held back in the 8.6.5 image previously (:facepalm:), but there was probably a good reason (at the time?). With 8.8.3, I think it makes sense to support both stretch and buster with stretch continuing to be the default. For 8.10.1 we could make buster the default and shoot for supporting the latest two Debian releases going forward? Does this sound like a reasonable approach?

I've briefly played with a few combinations of Debian/GHC/STACK to see what works but haven't published my WIP branch publicly yet (based on this branch atm). We also have the logistics problem of not being able to use build targets or build args in the official images process, so we will need to wire up a Dockerfile generation process (or just maintain them by hand for now).

:wave: @AlistairB thanks for the PR, any questions/opinions on the above? I'll have more feedback and a branch to look at soon.

AlistairB commented 4 years ago

Hi :wave:

My 2c.. I like the trend among other languages of:

https://hub.docker.com/_/ruby is a pretty good example of this style.

I think it is up to the small percentage of users that have very strict requirements on tooling to have their own custom dockerfiles so they can control these versions. Or to pin the dockerfiles to the sha to avoid undesirable updates. (I'm assuming this is why you wouldn't want to update stack / cabal in older GHC versions?)

I agree that existing versions retaining their OS version is reasonable. ie 8.8.3 = stretch (and an additional 8.8.3-buster would be added), however 8.10.1 = buster (with 8.10.1-stretch). (Although interestingly it seems most languages just default to a single debian version across the board for all supported language versions)

Anyway, happy to modify this PR as required or close it in favour another solution :)

psftw commented 4 years ago

@AlistairB I think we agree on everything, and I've come around to the idea that we might as well just have Buster be the default for consistency. I've created a new PR which also fixes the GitHub Actions so that PRs will build and smoke test the full matrix going forward. Thanks for getting involved, and if you have time to review, much appreciated! :heart_decoration:

psftw commented 4 years ago

Oh, I should add, there is a reason we get two keys for stack: https://docs.haskellstack.org/en/stable/SIGNING_KEY/#signing-key

In effect, we are validating the relationship between the FPComplete signing key and the release key (which is admittedly a bit overkill).

AlistairB commented 4 years ago

Thanks @psftw sounds good! :heart: