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

[AlistairB]

Closes #8

• Updated 8.6, 8.8 to buster.
• Updated 8.6 to stack 2.1.3
• Updated 8.6 to use cabal 3.0
• gpg key C5705533DA4F78D8664B5DC0575159689BEFB442 is not needed in buster.. apparently.. so I deleted it.

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]

@psftw I'm still a bit confused about whether this is reconcilable with the conservative goals you stated in #6 (comment) 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]

@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).

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

[AlistairB]

Hi 👋

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

• maintaining -stretch and -buster variants.
• maintaining -slim variants based on debian -slim. (Although, I think for a language like Haskell with no runtime system this is less important. I build with haskell, but run with debian:stretch-slim so I don't care much about levels of bloat in haskell.)
• updating all images with up to date language tooling. I think in 90% of cases this is what people want. New tooling is better, assuming it supports old language versions.

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]

@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! 💟

[psftw]

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]

Thanks @psftw sounds good! ❤️