Remove Alpine support -- or add it throughout the CI stack

[baentsch]

As mentioned in open-quantum-safe/ci-containers#97 (review), why does liboqs still support Alpine in CI? Wouldn't it suffice to only run on Ubuntu? This would
a) be in line with what is stated in PLATFORMS.md
b) eliminate the need to improve the ci-containers workflow to include building alpine docker images (currently not done, necessitating manual work to update the alpine images, e.g., to make CI pass on #2303).
c) generally ease contribution and maintenance

As git-blame points to @dstebila as the person introducing Alpine 4 years ago, can you maybe comment? Would you agree it'd be easier to use just using one docker image for all tests? Or is there a reason for prioritizing Alpine over Ubuntu in some tests? In that case, we should update PLATFORMS.md and the build-and-push logic in ci-containers.

[baentsch]

Tagging @dstebila @xuganyu96 for input. If none is received, I'd suggest changing all CI jobs over to drop anything other than Ubuntu:latest.

[hippi777]

alpine uses musl, while ubuntu is glibc only... musl is nearer to standards (posix/whatever else?), so it can be good for compatibility but statically linking musl or any other c lib on ubuntu should yield the same results (i believe), even if anything else uses a dynamically linked glibc... also, alpine is small, so even ubuntu could be questioned... :D

(note that im not much familiar with this code base, im just around for learning and seeing news...)

[xuganyu96]

alpine uses musl, while ubuntu is glibc only... musl is nearer to standards (posix/whatever else?), so it can be good for compatibility but statically linking musl or any other c lib on ubuntu should yield the same results (i believe), even if anything else uses a dynamically linked glibc... also, alpine is small, so even ubuntu could be questioned... :D

(note that im not much familiar with this code base, im just around for learning and seeing news...)

Seems like a fair point. Perhaps this is the reason why Alpine was added to the list of test targets in the beginning.

@baentsch @dstebila I think for now the correct path forward is to update the ci-alpine-amd64:latest image with the updated Dockerfile. Unfortunately I don't have the DockerHub permissions to push on my own, but I can raise a PR on ci-containers to add ci-alpine-amd64:latest to the automated build-and-push workflows.

[dstebila]

As git-blame points to @dstebila as the person introducing Alpine 4 years ago, can you maybe comment? Would you agree it'd be easier to use just using one docker image for all tests? Or is there a reason for prioritizing Alpine over Ubuntu in some tests? In that case, we should update PLATFORMS.md and the build-and-push logic in ci-containers.

I see an older commit attributed to @baentsch. :) The oldest commit I can see mentioning Alpine (in ci-containers) is by Goutam, but even then I think he may not have been the instigator of this; my vague recollection is that it came from some external prompting. I seem to recall that the arguments for including Alpine were the same ones that @hippi777 points out above: it did not use glibc, and also that it had very small images.

My gut feeling is that there's probably value in doing CI on at least one other Linux distro besides Ubuntu, though I have not enough familiarity with the variety of Linux distros to know what a good choice would be or even how to make that choice.

[hippi777]

im not really familiar with this code base, maybe the available tools and their freshness matter more or less... alpine uses busybox in place of gnu coreutils (and probably more), but i think it is more important to test clibs and the supported architectures of the distro... i think both alpine and ubuntu support many architectures, including risc-v, as probably the most important exotic architecture, and probably x86 too... void linux is my main os, which is somewhat near to alpine, maybe worth a look, but probably alpine wins in this case, except that void is a rolling release distro by its very nature (but not cutting edge), and alpine edge (its dev branch) is broken oftentimes, if freshness+musl is what you would wish for, maybe its not the best aim for ci to shoot at a moving target, as that basically recreates an environment every time, but keeping cached packages outside and moving forward at will is possible, and void is very hacker friendly... also, alpine is used on many routers (openwrt), phones (postmarketos), and in containers... i think gentoo supports uclib (and maybe others) for some limited extent... nixos and guix are about reproducible builds, which might be interesting in itself... and lastly, i wonder about the impact of static/dynamic linking, as possible optimizations (lto/wpo) differ between these, and crypto stuffs are sensitive beasts, which shouldn't be outsmarted by compilers to behave well, so therefore it might matter to have a distro that supports a given clib without the need for static linking...

after all, i believe alpine+debian/ubuntu are fine choices, and these should already cover the most important things, while folks using more exotic stuffs will probably yell when they will need to, and probably they should know better anything like so...

[baentsch]

I see an older commit attributed to @baentsch. :)

Indeed my mistake, apologies: I should not have done that "quick fix" but created automation in ci-containers -- as now properly done in open-quantum-safe/ci-containers#98 (thanks @xuganyu96 !)

Thanks for these thoughts @hippi777 . Let's then add alpine to the documented CI-supported platform list so the next people looking at things don't wonder again.