@vitaliikuzhdin I see what you mean now. When I started there were no multiple versions of runtimes in the official repos (tbh the official packages didn't actually exist) and people were specifying the version in their dependencies instead.

That did change in the recent year(s) but these packages still don't reflect that. I will make the changes tomorrow.

@Gr3q, ah, I just noticed you started removing those provides entries on the dotnet-core-bin packages. However, those are correct for the unversioned -bin package and should be brought back. I was only referring to the versioned packages (dotnet-core-x.x*).

@Gr3q,

I'm not sure what you mean, what exactly is the problem with this package?

You need to remove provides=("dotnet-runtime=${_runtimever}") and similar, because these are incorrect. To provide an up-to-date package means to be a drop-in replacement of the same version, otherwise, errors can occur like the one described above.

You don't even have it installed.

That's false. And how is that even related? Do I need to install packages with incorrect provides to know they have incorrect provides? Or can I simply read the PKGBUILD?

@vitaliikuzhdin I'm not sure what you mean, what exactly is the problem with this package? You don't even have it installed. This package provides dotnet-*-8.0 packages and their exact versions (the thing that actually differs from the official packages in the provides section)

@Gr3q, so at least the runtime packages shouldn’t have the provides. As for the SDK, it can indeed target older .NET releases for the build, but not for many other functions. For example, running dotnet restore fails if the version is mismatched:

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'restore' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 8.0.405
global.json file: (...)/global.json

Installed SDKs:
9.0.306 [/usr/share/dotnet/sdk]

Install the [8.0.405] .NET SDK or update [(...)/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

Arch packages that claim to provide another package should be drop-in replacements for what they are providing, which is clearly not the case here. I guess this is also the reason the official versioned .NET packages do not have provides. I don’t think deviating from the official packages is a great choice.

Is there a reason your versioned .NET packages claim to provide their newer counterparts? For example, if I try to build a 8.0 project using the 9.0 SDK, it fails, and the same applies when running projects that depend on an older runtime with a newer runtime. The official source-built packages don’t provide this either. Or am I missing something?