Simplify RID graph

[richlander]

We made a change a few years ago to stop updating the runtime.json file. It is now stale and offers little to no value.

• https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json
• https://github.com/dotnet/designs/blob/main/accepted/2022/simplify-rid-model.md
• Make host look for RID-specific assets via a known list by default #84100
• Remove host compatibility mode for runtimes.json #123009
• dedd914

The overall intent is to make runtime.json match the algorithmic mode in the host. However, that may be too breaking. The primary user of this file (AFAIK) is dotnet restore.

It's easiest to make this change with a somewhat explanatory PR description rather than write a spec and ask for feedback. Well, the spec was written 4 years ago and basically describes the plan except for this step.

Plan

• Keep all portable RIDs (roughly anything with any or unix as a base; matches the host)
• OSes at a peer to linux are considered portable, such as: feebsd, illumos
• Keep all Apple OSes and their simulator variants
• All UI-focused OSes should be added as root RIDs, like android and tizen, even if they are Linux derivatives as an implemtentation detail.
• Keep all win related RIDs
• Remove all non-portable Linux RIDs, like alpine (use a portable RID like linux-musl)
• Remove all versioned RIDs, like android.32 and ios.15

Result

Before:

$ wc src/libraries/Microsoft.NETCore.Platforms/src/runtime.json
 4629  6226 76580 src/libraries/Microsoft.NETCore.Platforms/src/runtime.json

After:

$ wc src/libraries/Microsoft.NETCore.Platforms/src/runtime.json
  761  1020 11688 src/libraries/Microsoft.NETCore.Platforms/src/runtime.json

wc format: lines words bytes file

That's a reduction of (almost) 4k lines and 60k+ bytes. This isn't a high-performance scenario so that's not the reason. It's a realization that almost all of the file is stale and serves no purpose and was based on an old plan (hence why the file hasn't been updated in 1.5 years). It is possible that reducing the file size will improve some memory use metrics (measured or otherwise).

Compatibility

• Last change (August 2024): dedd914
• Last relevant change (June 2023): c6b41ad

The point here is that the last couple changes are still persisted in the the reduced file. The addiition of Debian 12 in the second change will be undone by this change. Debian 13 was never added (shipped long after the freeze of the file).

The open question is how to validate this change. This may well be correct, but we want to understand the likelihood of breakage. Another question is how much coverage we have in this tree for this tree. It is likely that I need to do some kind of search on nuget.org.

As a case in point, how do we reason about removing alpine.3.17, for example? This means that there was some change in Alpine 3.17 that wasn't in Alpine 3.16. If it was in Alpine 3.16, then alpine should have been used as the RID. The transition from OpenSSL 1.x and 3.x happened between those two versions. Alpine 3.16 has been EOL since May 2024.

Then, why use alpine vs linux-musl? There isn't a reason. There is nothing we can guarantee about what alpine delivers over linux-musl. You have to use documentation over and above the RID to ensure that the code works.

All that said, there will be some packages that use these RIDs for good or bad reasons. And that's the compatibility risk.

Reference: https://alpinelinux.org/releases/

[Copilot]

Copilot wasn't able to review any files in this pull request.

[richlander]

@am11 @elinor-fung @agocke @nkolev92 @ericstj @jkotas @baronfel

[baronfel]

Haven't taken an in-depth look, but I think the complete removal of tizen might need to be considered a bit - that too is an interesting 'root' in the same way as android/ios from what I understand. At least, our bundled packs versions have it as an explicit known RID, so we'd need to be able to relate tizen to something else in the graph.

[richlander]

Fair. Anything with a UI stack should have a root. I can add that back.

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this PR has the breaking-change label.

When you commit this breaking change:

1. Create and link to this PR and the issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.
2. Ask a committer to mail the .NET Breaking Change Notification DL.

Tagging @dotnet/compat for awareness of the breaking change.

[ericstj]

The overall intent is to make runtime.json match the algorithmic mode in the host. However, that may be too breaking. The primary user of this file (AFAIK) is dotnet restore.

So this RID graph flows into the SDK and it redistributes it as RuntimeIdentifierGraph.json. It's used by Nuget during restore when folks specify a RID to decide which single runtime asset will be selected for that RID. The package also ships a copy which allows RIDs to be added out of band from the SDK.

We also used this RID graph when generating the fallback RID list that goes into the shared framework's deps file. This was used by the host when determining precedence of runtimeTargets. I'm not sure if that's still done or not - or if the runtime still needs those or not - since a lot of this changed when the runtime stopped using versioned RIDs. FWIW I still see those versioned RIDs in the shared framework's deps file.

The open question is how to validate this change. This may well be correct, but we want to understand the likelihood of breakage.

Enumerate restore scenarios and call out what breaks. Consider restoring for specific RID, and also consuming packages which use specific RIDs.

Also test loading of assets which have RID-specific runtime targets. If we drop RIDs from the shared framework deps file those will break too.

What I'm not so sure about is how much of this was already broken/not, and how much of this already got warnings and for how long.

[richlander]

It's already fully broken for new OSes so this is solely about older OSes (all non-latest and many EOL).

A challenge is that we never gave guidance on how to use RIDs correctly. So, an incorrect and unsupported use could still "work".

Do you have any tests for RID-based restore @nkolev92?

[nkolev92]

We do have various unit tests for rid being used during restore, but we don't really test the true mapping, but rather just basic ones we create in our code to test the functionality itself, that being rid based asset selection and the fact that runtime.json is used at restore.

The way to probably estimate potentially affected packages would be to look on nuget.org for packages that have rids that are no longer represented in this runtime.json.

I don't know of a way to do the reverse (basically a soon to be unknown rid being used on the project side), as that's not something we track in any way.