@kasper3 commented on Sun Mar 11 2018

Sabotage Linux - http://sabotage.tech/
Void Linux - https://www.voidlinux.eu/
NodeOS - http://node-os.com/

are some examples of musl-libc based linux distributions. Here is a full list: https://wiki.musl-libc.org/projects-using-musl.html.

Currently microsoft/dotnet:2.1-sdk-alpine docker image has hardcoded alpine name in it and unlike dotnet-sdk-latest-linux-x64.tar.gz distro-agnostic package, there is no way of using alpine package on any-musl distro.

Please consider renaming alpine docker and tarball to have musl in its name instead of alpine, so other distros based on this libc can get the (non-official) support.

Example of using .NET Core on some non-officially supported glibc-based distros:

• Mageia Linux - https://gist.github.com/anonymous/1b45b87032d62bf20bf28ad7512ea178 (listed on top 10 on distro watch https://www.distrowatch.com/dwres.php?resource=major)
• Clear Linux - https://github.com/dotnet/coreclr/issues/9055#issuecomment-371758941

CC @janvorli @MichaelSimons

@Petermarcu commented on Sun Mar 11 2018

You should be able to publish for Alpine and use it on other musl-libc based distros.

My understanding is that in addition to just supporting musl-libc, we would have to make sure the binaries are created in a distro agnostic way with respect to other dependencies like openssl and libunwind.

@kasper3 commented on Sun Mar 11 2018

@Petermarcu, sure the same way there are fallback lookup paths for dependency lib names in glibc-based distros. Those fallback paths in core-setup/coreclr/corefx repos can even be added later.

However, with alpine hardcoded in RID name without a base RID with musl-libc is not neutral. Before 2.1 if this gets renamed to *musl-libc* that would be a great achievement in terms of future proofing, otherwise we are going to stick with alpine-* forever or encounter a breaking change when it's time to support the second musl-libc distro.

@Petermarcu commented on Sun Mar 11 2018

I think thats something we can consider. We'd have to make the graph something like this: linux-x64->musl-linux-x64->alpine-x64->alpine.3.6-x64. And make sure the implementations that are in the alpine.3.6-x64 packages end up in the linux-musl-x64 packages. I'm going to move this to the core-setup repo where it can be tracked.