New package: dotnet-sdk-2.2.203

[Anachron]

Right now I decided to not add a PR for dotnet-runtime because it doesn't seem to work without the sdk. Should resolve #10773.

Here is an example output of dotnet --info after installation:

.NET Core SDK (reflecting any global.json):
 Version:   2.2.203
 Commit:    e5bab63eca

Runtime Environment:
 OS Name:     void
 OS Version:  
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /opt/dotnet/sdk/2.2.203/

Host (useful for support):
  Version: 2.2.4
  Commit:  f95848e524

.NET Core SDKs installed:
  2.2.203 [/opt/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.2.4 [/opt/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.2.4 [/opt/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.2.4 [/opt/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

[Duncaen]

This was not ready to merge, 1. its a binary package, 2. /opt, 3. typo in archs, 4. vendored license.

I reverted it in bdc0219 before someone starts merging packages depending on it.

[Anachron]

1.) Whats the problem?
2.) Where should I install it to then?
3.) Which one?
4.) Whats the issue?

Please let me know what is needed so I can fix it.

[Johnnynator]

1.) Whats the problem?

• No -bin Suffix
• Does not support -musl even so that e.g. alpine seems to be supported by upstream

3.) Which one?

armv7 -> armv7l

4.) Whats the issue?

Licenses should always be fetched from upstream, there is no guarantee for them to be up to date if we vendor them.

[Anachron]

1.) Ok so it should be called dotnet-sdk-bin?
There is only one musl for x86_64. I could package that one as well but wasn‘t sure how useful that was.
3.) Thanks, didn‘t catch it.
4.) So I should use a cat/sed in my install script and extract license from the source?

[Duncaen]

The optimal solution would be to build this from source.

Having binary package in the repository comes with side effects if they depend on other libraries, we would have to wait for new releases to be built against the library version we use, this either blocks updates or if we forget about it, keeps the whole repo in staging.

[Anachron]

Okay I‘ll repackage it as a source package. Sorry I didn‘t know about all of this, thanks for letting me know!

[Anachron]

I am not sure how I should build it from release correctly.

So far I found https://dotnetcli.blob.core.windows.net/dotnet/Sdk/release/2.2.3xx/dotnet-sdk-latest-linux-x64.tar.gz on https://github.com/dotnet/core-sdk#installers-and-binaries which is not a fixed version but rather from the 2.2.3 branch.

The website https://dot.net/core does not provide any source code as well. The PKGBUILD from AUR seems to fetch the latest version from Github: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dotnet-core

So I'm out of ideas how to build it from source in a way that Void Linux would accept it. I'd just go ahead and fix the remaining issues on this template and call it dotnet-sdk-bin.

[Johnnynator]

You could fetch all the tarballs from Github. But beware they build system is just pure pain to work with, and would require patching to for us, it also fetches prebuilt dotnet toolchain.
You can find some intresting documents in the source-build repo in regards of packaging and bootstrapping status https://github.com/dotnet/source-build/tree/release/3.0/Documentation

So currently there is no easy way to get it properly packaged for Void.

[rmboggs]

If there currently isn't a clear path to packaging dotnet sdk for void linux, does anyone who has successfully installed dotnet sdk on void linux have any documentation or steps taken so others, like myself, can get it up and running in the meantime?

[agausmann]

This also doesn't seem to be fully tested. I just tried compiling a project with this package and it yelled at me with "No usable version of libssl was found." with both libssl46 and libssl47 installed. Turns out .NET also doesn't officially support libressl, which is going to complicate things even further.

[rmboggs]

I saw that today when I tried buildin this branch. I read somewhere that symlinking to libssl.so seems to work but definitely not supported. Not sure what to do next.

[vikigenius]

Yeah, I ran into the same problem as well. Right now I have no idea how to proceed further.

[agausmann]

So I have a workaround in place: Make sure libssl46 is installed and set the environment variable CLR_OPENSSL_VERSION_OVERRIDE=46. Everything seems to run fine with that setup, so it seems dotnet doesn't really care whether it is libressl or openssl to some extent, we just have to configure it to use the correct version.

[Anachron]

A little update on the dotnet-sdk & jellyfin situation:

=> jellyfin-10.3.7_1: running do_build ...
Cannot get required symbol d2i_ASN1_type_bytes from libssl
/void-packages/srcpkgs/jellyfin/template: line 24: 17910 Aborted
 dotnet build --configuration Release Jellyfin.Server
=> ERROR: jellyfin-10.3.7_1: do_build: 'dotnet build --configuration Release Jellyfin.Server' exited with 134
=> ERROR:   in do_build() at srcpkgs/jellyfin/template:27

Templates are here:
#6684 (comment)

[Anachron]

If someone is still looking for how to get Jellyfin/dotnet-sdk working on Void, head over to #6684 (comment)