Package Details: dotnet-runtime-2.1 2.1.18.sdk806-2

Git Clone URL: https://aur.archlinux.org/dotnet-core-2.1.git (read-only, click to copy)
Package Base: dotnet-core-2.1
Description: The .NET Core runtime version 2.1
Upstream URL: https://www.microsoft.com/net/core
Licenses: MIT
Conflicts: dotnet-runtime=2.1.18.sdk806, dotnet-runtime-2.1
Provides: dotnet-runtime=2.1.18.sdk806, dotnet-runtime-2.1
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 2
Popularity: 0.33
First Submitted: 2019-10-05 06:40
Last Updated: 2020-05-14 17:33

Required by (30)

Sources (3)

Pinned Comments

Gr3q commented on 2019-10-05 07:32

IMPORTANT INSTALLATION INFO (a reminder for myself as well):

For dotnet to work you need to EXPLICITLY install:

  • ONE dotnet-host - highest version possible
  • ANY NUMBER of dotnet-runtimes (and its sdks after if you want to build as well - Right now version 'bin' and '2.1' is tested to work together)

If you keep the install order in mind and you don't rely on pacman to resolve your dependencies you will be fine.


Longer explanation:

Every dotnet-sdk is dependent on a specific version of dotnet-runtime, this is built into dotnet.

Technically you only need the latest dotnet-sdk because it can build to any earlier versions.

Because you are installing from the AUR pacman won't resolve dependencies for you correctly with specific versions, and the installation will either fail or the (outdated) community package will be installed as dependency.

Latest Comments

1 2 Next › Last »

Gr3q commented on 2020-04-16 21:03

@Zoidberg_md Alright, They are up. I will work on the first problem, and update them when I figured out a solution.

zoidberg_md commented on 2020-04-16 15:58

@Gr3q

  1. 2.2-latest might be necessary. because after-EOL updates are possible, e.g. XP had a couple of pathes after the EOL. Also, having -latest makes things simpler for people who don't run into problems.

As for older SDKs, my understanding is that multiple Android SDKs are necessary, because Android devices are non-updateable. So you need to test your app against all older API versions which are still found in the wild.

With Dotnet Core, the situation is hopefully not that terrible. So I think supporting all IDE+target combinations is enough. So I'm for 2.2-2017 and 2.2-2019 without all older SDKs.

Gr3q commented on 2020-04-16 14:54

@Zoidberg_md

  1. Got it
  2. Mainline was a bad choice of word. I meant that both SDKs depend on the same runtime. So I create a "main" package for 2.2 with the latest versions - what is kind of unnecessary because it is EOL - and create specifically versioned ones like android-platform.
  3. I see. I'm aware that official packages build from source.
  4. Ok, I just thought there was a reason why it was like that.

So all in all, would it be more useful to have the latest VS2017 and VS2019 SDKs up on AUR, or all older SDKs and their runtimes explicitly versioned like in the link above?

I think the former can become confusing if at the end of the day all you need is specific versions of the SDKs installed.

zoidberg_md commented on 2020-04-16 13:21

It's to minimize compatibility issues. If compatibility was perfect, MS wouldn't have released multiple branches in the first place. So the Linux branch is for cross-platform development with VS2017 on Windows side. Also I think it's better to release whatever upstream releases. So 1 runtime and 2 SDK packages. You can look at https://dotnet.microsoft.com/download/dotnet-core/2.2

  1. Install the package, then run dotnet build under non-root.

  2. The dotnet-host is designed to interoperate with multiple SDKs and runtimes installed. So the situation is closer to python/python2. And the only way to have both VS2015 and VS2019 SDKs installed in Arch is to have different package names. The scenario is useful e.g. in case of continuous integration builds where we want to run tests with different SDK versions.

What do you mean by mainline? Is it for community/extras? The .Net core mainline is 3.1 LTS now AFAIK, there's no such thing as "2.2 mainline"

  1. They were built from sources, but at some time someone changed them to use binary releases instead. E.g. the official Archlinux dotnet-core builds from sources still.

  2. I just was lazy to replace them, as I have no way to validate them. You are supposed to fix that. Or I can do if you are interested.

  3. OK

Gr3q commented on 2020-04-16 12:54

@zoidberg_md Can you clarify some things for me? I need all of this to understand the requirements so I can come up with correct solutions.

First what is the use case to have the VS2017 branch on Linux when VS can't be used? Is it an issue because you need that specific SDK to compile something? I thought All SKD-s are good on the same branch - 2.2 - as long as it has higher version. (I'm not actively use the SDK on Linux at the moment, so I don't know)

About the other questions:

  1. When does this happen, what do you do for this to happen? So I can replicate it and come up with something.

  2. If both SDKs are needed, I just need to create the mainline packages for 2.2 then upload the other version as well, as they depend on the same Runtime

  3. Never validated that to be honest, I'll have a look removing it.

  4. Why do you use the newer SDK on armv7h and aarch64? Because it does not make a difference?

  5. It's absolutely ok to have the EOL versions up here if needed (I completely forgot to upload 2.2...I promised to do it months ago)

zoidberg_md commented on 2020-04-15 17:29

I made a quick and dirty version for dotnet 2.2: https://pastebin.com/zuDPxgQW

It's very dirty, sorry, but works for me with current dotnet-host from the official Arch repos, so I thought that publishing it might be useful for someone. Some thoughts:

  1. Someone should include a pacman hook to avoid "Permission denied to modify the '/usr/share/dotnet/sdk/NuGetFallbackFolder' folder" warning.

  2. There are 2 SDKs. Someone could create a different subpackage for .2xx branch which ships with VS 2019

  3. The packages are in fact binary, so a) build dependencies aren't necessary, and b) the packages should be named even more funny, something like dotnet-runtime-bin-2.2 and dotnet-sdk-bin-2.2-{2017,2019}

  4. The binaries for non-x64 architectures are wrong. The links should be taken from the .json file in the comments in the PKGBUILD. The process can be semi-automated.

  5. 2.2 is EOL, but it's the only way with VS2017

satcom886 commented on 2019-10-05 10:25

@Gr3q You are awesome! Thanks!

Gr3q commented on 2019-10-05 10:23

@satcom886 I disabled the aspnet-runtime package because aarch64 is not supported for that (and it obviously should not prevent you installing the other packages).

I'll split it to a separate package if I don't find a way include it in here without blocking.

satcom886 commented on 2019-10-05 10:16

@Gr3q Yep, I tried to install dotnet-runtime-2.1 (for Jellyfin), but it threw an error that aspnet-runtime-2.1 is not available aarch64.

Gr3q commented on 2019-10-05 10:00

@satcom886 does the lack of aspnet support for aarch64 prevents you to install the other packages? (named dotnet-host, dotnet-runtime and dotnet-sdk)