Add Fedora 36 to the RID graph

[omajid]

Fedora 36 is under development:

$ podman run -it registry.fedoraproject.org/fedora:rawhide /bin/cat /etc/os-release
NAME="Fedora Linux"
VERSION="36 (Container Image Prerelease)"
ID=fedora
VERSION_ID=36
VERSION_CODENAME=""
PLATFORM_ID="platform:f36"
PRETTY_NAME="Fedora Linux 36 (Container Image Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:36"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Container Image"
VARIANT_ID=container

I couldn't get the changes runtime.json to show up until I built with a customtarget. I updated readme.md with that extra information too.

[ghost]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[omajid]

Hey @ViktorHofer am I doing something wrong with /t:UpdateRuntimeJson? Should it have worked out of the box?

[ViktorHofer]

Hey @ViktorHofer am I doing something wrong with /t:UpdateRuntimeJson? Should it have worked out of the box?

I don't know what UpdateRuntimeJson is exactly doing without looking into its sources. I think @ericstj should be able to answer.

[ericstj]

am I doing something wrong with /t:UpdateRuntimeJson? Should it have worked out of the box?

It would have when running pack. If you aren't packing you can run the target directly. I think the docs are unclear about this since they say "rebuild the project" which made sense when it was a dedicated pkgproj but is no longer the best wording now that it's a CSProj. I'm fine with the update you made to the docs.

[ViktorHofer]

Merging as the previous run was successful and the recent commit just update a docs file.

Thanks a lot @omajid

[tmds]

@ericstj@ViktorHofer I thought, thanks to #50818, we no longer have to make these changes?

[ViktorHofer]

You likely want what's proposed in NuGet/Home#5862 as well. #50818 helps with source build as you can define a new RID via a variable but I don't see how this would help when not source building.

[tmds]

#50818 helps with source build

Yes.

I don't see how this would help when not source building.

I'm not aware of issues.
If there are, probably they can be addressed to make this type change also unnecessary for non-source build.

[tmds]

I changed my /etc/os-release to pretend it's the non-existing Fedora 40.
I then built clr+libs+libs.tests and ran tests. This worked fine.

@ViktorHofer@ericstj unless we know why we need them, can we stop adding new distro versions RIDs?

[ViktorHofer]

How would you add fedora.40 specific package assets that shouldn't include to fedora.39 without having rids per version?

[tmds]

How would you add fedora.40 specific package assets that shouldn't include to fedora.39 without having rids per version?

In practice, we've seen this is not scalable and it can cause applications to fail when a system is upgraded from one version to the next.

Instead, I'd add assets for all supported Fedora versions, and pick the most appropriate at runtime (e.g. using NativeLibrary).

For example LibGit2Sharp does this: https://github.com/libgit2/libgit2sharp/blob/6329bea6d315f563d7107982bccbea4325947808/LibGit2Sharp/Core/NativeMethods.cs#L149-L151.

[ViktorHofer]

In practice, we've seen this is not scalable and it can cause applications to fail when a system is upgraded from one version to the next.

My assumption is that the current design isn't scalable because of the issues listed in NuGet/Home#5862.

cc @ericstj for his opinion

[ericstj]

#50818 helps folks avoid source changes when building dotnet/runtime on new distros. It doesn't eliminate the need to have discrete RIDs listed in the RID graph in order to support those new distros at runtime/design-time. The Host, NuGet, and SDK still depend on that. I'd love to see us eliminate that in v.Next. cc @richlander

[richlander]

My most frequent experience with this is with Alpine, which ships frequently. We're almost always waiting on new RIDs to release a new Alpine. That makes little sense to me.

I think the order should be (using existing versions as examples):

• Release new .NET 5 container images for Alpine 3.14, ASAP.
• Declare somehow that Alpine 3.14 is equivalent to Alpine 3.13 (which has an existing RID)
• This means we don't have to wait on ANY product changes.
• At our convenience (within 2 months), add Alpine 3.14 to the RID graph so that people can explicitly target it.

Perhaps we could do this today, but it's not what we do.

/cc @mthalman

[tmds]

At our convenience (within 2 months), add Alpine 3.14 to the RID graph so that people can explicitly target it.

For distros that move fast like Fedora and Alpine, we continuously need to upgrade the rid graph.
As I mentioned earlier, it is not only a scalability issue for us updating the graph, but also the same scalability issue exists for users targeting these individual rids.

That makes it impractical to use these rids, and a preferable solution is to do assets selection at runtime using NativeLibrary, RuntimeInformation.RuntimeIdentifier, ...

It may still be interesting to target the parent rid (e.g. fedora-x64).
We can extend the Host, NuGet, and SDK, ... so they have some logic like #50818.
That means when .NET runs on the unknown alpine.3.14-x64, it will still consider alpine-x64 assets.

@richlander@ericstj your thoughts?