runtime
runtime copied to clipboard
runtime: add RIDs for anolis distro
instead of patching dotnet everytime after it got updated we plan to add runtime ID for anolis 7/anolis 8/anolis 9.
Signed-off-by: Livy Ge [email protected]
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries See info in area-owners.md if you want to be subscribed.
Issue Details
instead of patching dotnet everytime after it got updated we plan to add runtime ID for anolis 7/anolis 8/anolis 9.
Signed-off-by: Livy Ge [email protected]
| Author: | geliwei |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
@richlander is usually involved in the flow for adding new distros to the graph. Rich?
/cc @agocke
We are currently considering this design proposal.
https://github.com/dotnet/designs/pull/260
I don't think we can reasonably back-port it to .NET 6, however.
Can you share more context? Are you the maintainers for .NET for anolis?
@geliwei can you please answer @richlander’s question?
I was thinking more about this (based on our continuing conversations on RID simplification). Is the RID for anolis needed for restoring anolis-specific packages or just to ensure that anolis is correctly treated as either rhel or linux?
I was thinking more about this (based on our continuing conversations on RID simplification). Is the RID for anolis needed for restoring anolis-specific packages or just to ensure that anolis is correctly treated as either
rhelorlinux?
Hi,
Yes, I'm the maintainers for Anolis distro.
It's good if the Anolis is treated as rhel.
I wrote these RID maps manually, I remebered there is a way to automatically work out RID graph via build.sh command, but I forgot on which post I found it.
I heard some news that you guys are working on code that could created RID on the fly, is that true ? D:
Hey @geliwei ! If you don't add the RIDs (manually or otherwise), does the .NET build fail? Can you point us to any build logs that show the failure?
This info might be what you are looking for: https://github.com/dotnet/runtime/pull/50818
We have a maintainers group now. I can add you if you want to join it @geliwei.
The new plan for source-build is documented at https://github.com/dotnet/designs/pull/260/files#diff-20aa11d3c5c8d54fc1c45f4b81927255d3951fdd7cf58589fc6d03a2dd2a6a1bR195.
Hey @geliwei ! If you don't add the RIDs (manually or otherwise), does the .NET build fail? Can you point us to any build logs that show the failure?
I copy a few errors from http://build.openanolis.cn/kojifiles/work/tasks/7092/297092/build.log: /builddir/build/BUILD/dotnet-v6.0.105-SDK/previously-built-dotnet/sdk/6.0.104/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(129,5): error NETSDK1083: The specified RuntimeIdentifier 'anolis.8.6-x64' is not recognized. [/builddir/build/BUILD/dotnet-v6.0.105-SDK/src/runtime/artifacts/source-build/self/src/Build.proj] /builddir/build/BUILD/dotnet-v6.0.105-SDK/previously-built-dotnet/sdk/6.0.104/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(129,5): error NETSDK1083: The specified RuntimeIdentifier 'anolis.8.6-x64' is not recognized. [/builddir/build/BUILD/dotnet-v6.0.105-SDK/src/runtime/artifacts/source-build/self/src/Build.proj] /builddir/build/BUILD/dotnet-v6.0.105-SDK/previously-built-dotnet/sdk/6.0.104/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(129,5): error NETSDK1083: The specified RuntimeIdentifier 'anolis.8.6-x64' is not recognized. [/builddir/build/BUILD/dotnet-v6.0.105-SDK/src/runtime/artifacts/source-build/self/src/Build.proj] /builddir/build/BUILD/dotnet-v6.0.105-SDK/previously-built-dotnet/sdk/6.0.104/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(129,5): error NETSDK1083: The specified RuntimeIdentifier 'anolis.8.6-x64' is not recognized. [/builddir/build/BUILD/dotnet-v6.0.105-SDK/src/runtime/artifacts/source-
I have made change to init-distro-rid.sh and also pal.unix.cpp, remove RIDs in runtime.json but keep runtimeGroups.props. But looks like it fails the test again, Would you like to help me figure out why?
I have made change to init-distro-rid.sh and also pal.unix.cpp, remove RIDs in runtime.json but keep runtimeGroups.props. But looks like it fails the test again, Would you like to help me figure out why?
this change works so far on dotnet5.0 https://gitee.com/src-anolis-os/dotnet5.0/commit/39c160eb817b5bab7366ed1d14f8c91d4316ca96
did we reached conciliation if new bistro is needed @omajid @richlander ?
As minimum we should rebuild other json files besides runtimeGroups.props and include this with the PR. (dotnet pack from https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.NETCore.Platforms/readme.md)
Ideally, we would not and this RID could be added via source-build per https://github.com/dotnet/runtime/pull/50818. That should be the goto approach for these cases. Is that acceptable?
Ideally, we would not and this RID could be added via source-build per #50818.
Would that mean that RH binaries would be unusable e.g. the RID would work only if distribution has own package created via source-build?
Here's my take/understanding on how the system should work.
- Everyone should publish portable linux binaries (for packages) as a general rule.
- If they cannot, then they limit the use of their package to specific OSes (probably just one specific OS).
- Publishing portable + specific is fine. I hope NuGet ignores RIDs it doesn't understand.
By building .NET for a distro as foo, you are not directly affecting package compatibility. You are saying "I'm this and I also accept the things I say I accept".
This is the same thing as blood types, where RIDs are like donors and distros are like recipients.
linux is like O- as a donor. It's universally compatible.
foo is like AB+ as a donor. It's universally incompatible, except with itself.
Credit to the Wikipedia page on blood types.
This is a fair analogy, right?
We can take the analogy a bit further. So far, we're only looking at two columns of donors (or RIDs). Let's look at the O+ donor column. That looks pretty close to the unix RID to me. The unix RID applies to Unix-like (or POSIX) OSes (Linux, macOS, and FreeBSD). It doesn't apply to Windows. O+ is more compatible than AB+ but less compatible than O-. That works pretty well. Note that there are other blood types with this same level of compatibility. I could have equally chosen one of the other but chose O+ only because it is more common.
I agree with @richlander, I think this is the correct direction.
@clairernovotny @aortiz-msft It would be good for the NuGet team to review this approach.
@aortiz-msft
cc @tmds who's been doing some recent work to make source build work without code changes to the RID graph.
So if I can summarize the state here, @richlander and @agocke are saying that this PR should not be needed due to the changes to how we expect distro's to source build in .NET 7.0. https://github.com/dotnet/runtime/pull/66132#issuecomment-1171793644
@geliwei do you agree, or are you keeping this PR open for a scenario that wasn't covered by that explanation?
Thanks! Eric
It would be good for the NuGet team to review this approach.
Ping @clairernovotny @aortiz-msft to help with this request.
are saying that this PR should not be needed
Ping @richlander @agocke to answer this question.
do you agree, or are you keeping this PR open for a scenario that wasn't covered by that explanation?
Ping @geliwei to answer this question.
are saying that this PR should not be needed
https://github.com/dotnet/runtime/issues/83246 is superseding https://github.com/dotnet/designs/pull/260 and is still being discussed.
As other rids are still being added, we can add these too.
The graph will be updated as needed for https://github.com/dotnet/runtime/issues/83246.
I'm closing new RID PRs for now, until we can sort out the RID plan, as in https://github.com/dotnet/runtime/pull/81115
I'm closing new RID PRs for now, until we can sort out the RID plan, as in https://github.com/dotnet/runtime/pull/81115
I'm not sure why this doesn't get added, while other rids are still being added.
Will we no longer be adding any rids until the RID plan is sorted out?
I have good hope we'll sort it out for .NET 8, but I had the same hope for .NET 7.
I'd keep business as usual until the plan is decided.