runtime icon indicating copy to clipboard operation
runtime copied to clipboard

runtime: add RIDs for anolis distro

Open geliwei opened this issue 3 years ago • 19 comments

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]

geliwei avatar Mar 03 '22 07:03 geliwei

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:

area-Infrastructure-libraries

Milestone: -

msftbot[bot] avatar Mar 03 '22 07:03 msftbot[bot]

CLA assistant check
All CLA requirements met.

dnfadmin avatar Mar 03 '22 07:03 dnfadmin

@richlander is usually involved in the flow for adding new distros to the graph. Rich?

bartonjs avatar Mar 17 '22 17:03 bartonjs

/cc @agocke

AaronRobinsonMSFT avatar Mar 20 '22 14:03 AaronRobinsonMSFT

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?

richlander avatar Apr 07 '22 19:04 richlander

@geliwei can you please answer @richlander’s question?

ericstj avatar May 02 '22 15:05 ericstj

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?

richlander avatar May 03 '22 17:05 richlander

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?

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:

geliwei avatar May 13 '22 13:05 geliwei

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?

omajid avatar May 13 '22 21:05 omajid

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.

richlander avatar May 15 '22 00:05 richlander

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-

geliwei avatar Jun 02 '22 06:06 geliwei

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?

geliwei avatar Jun 02 '22 06:06 geliwei

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

geliwei avatar Jun 02 '22 06:06 geliwei

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)

wfurt avatar Jun 30 '22 13:06 wfurt

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?

richlander avatar Jul 01 '22 00:07 richlander

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?

wfurt avatar Jul 01 '22 08:07 wfurt

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.

image

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.

richlander avatar Jul 01 '22 20:07 richlander

I agree with @richlander, I think this is the correct direction.

agocke avatar Jul 01 '22 21:07 agocke

@clairernovotny @aortiz-msft It would be good for the NuGet team to review this approach.

richlander avatar Jul 03 '22 18:07 richlander

@aortiz-msft

danmoseley avatar Aug 22 '22 15:08 danmoseley

cc @tmds who's been doing some recent work to make source build work without code changes to the RID graph.

ericstj avatar Oct 03 '22 16:10 ericstj

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

ericstj avatar Nov 28 '22 16:11 ericstj

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.

carlossanlop avatar Mar 13 '23 23:03 carlossanlop

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.

tmds avatar Mar 14 '23 04:03 tmds

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

agocke avatar Mar 14 '23 04:03 agocke

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.

tmds avatar Mar 14 '23 04:03 tmds