Community-supported platforms runtime and sdk installation via dotnet-install

[am11]

There are several community-supported platforms: linux-{musl-}s390x, linux-{musl-}ppc64le, linux-{musl-}riscv64, linux-{musl-}loongarch64, freebsd-x64, freebsd-arm64, illumos-x64 and haiku-x64.

We have cross-build images for all of them in https://github.com/dotnet/dotnet-buildtools-prereqs-docker, and some of them are used in the CI. The steps are pretty much the same for cross build.

Are there plans to support their SDK installation via aka.ms links

install-scripts/src/dotnet-install.sh

Line 1255 in 2ed8cce

aka_ms_link="https://aka.ms/dotnet"

? e.g.

existing official: aka_ms_link="https://aka.ms/dotnet"
+community: aka_ms_link="https://aka.ms/dotnet-community"

(just like how distros typically provide "community" packages https://pkgs.alpinelinux.org/package/edge/community/aarch64/dotnet8-sdk)

[am11]

cc @jkotas @baronfel @akoeplinger #480 (review)

[jkotas]

I do not expect Microsoft to host a download site for community-supported platform binaries.

We have cross-build images for all of them in https://github.com/dotnet/dotnet-buildtools-prereqs-docker, and some of them are used in the CI. The steps are pretty much the same for cross build.

From Microsoft point of view, these cross-build images are test-only assets.

[am11]

@jkotas, if community is responsible for maintaining the breakage, is integration with dotnet-install.sh still the right place to draw the line? e.g. dotnet-install.sh --enable-community ... gives a clear "it's unofficial" type of message.

Currently folks are creating artifacts and uploading to GitHub releases. In the end, they - too - are stored in Azure Blobs storage minus the inconvenience to not be able to obtain it via dotnet-install.sh.

It doesn't have to be aka.ms link, it could be a link provided by responsible team to enable this flow.

[jkotas]

The download site structure expected by dotnet-install.sh script is tightly coupled with the Microsoft .NET release management infrastructure that supports many different scenarios. dotnet-install.sh script grew into 2000+ lines to handle it all. I have doubts that the community supported ports would be interested to re-creating the download site structure expected by the dotnet-install.sh script. If a community supported port has a need for a download script, I think it is probably better for them to roll their own simple script.

It doesn't have to be aka.ms link

The script assumes that it is talking to aka.ms site and expects it to return redirect URLs. It is not a simple download a file from this URL.

[jkotas]

In any case, this discussion would be probably better suited for https://github.com/dotnet/install-scripts/ repo where the dotnet-install.sh script lives.

[am11]

dotnet-install is used in runtime build, which is why integration with this script is interesting and I opened the issue there. Actual functionality is really not that much, it's just the way it is written is too verbose.

[NikolaMilosavljevic]

[Triage] @leecow @rbhanda can you help move this issue to dotnet/install-scripts repo?

[YuliiaKovalova]

@baronfel please share your vision on this request.

[ellahathaway]

Following up on #618 (marked as a duplicate of this discussion), I wanted to highlight that when the standard aka.ms links are unavailable (for example, with older versions or specific versions for non-officially supported architectures), users can specify their own custom feeds via the --azure-feed or --uncached-feed options. This provides a pathway for community-supported or less-common architectures to get .NET builds by pointing to alternative repositories.

With that in mind, @uweigand: is there a store of .NET builds for IBM platforms (e.g., s390x) that users could point to as an alternative feed source?