Add missing OL releases to RID graph #66783
Conversation
Add Runtime Identifiers for missing OL releases. See https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.NETCore.Platforms/readme.md#adding-new-rids
ghost
added
the
community-contribution
|
|
|
I think a better long term approach is to teach the .NET Runtime to treat Oracle Linux "7.x" as just "7", "8.x" as "8", and so on. That's what it does for RHEL. There's also a proposal to freeze the runtime ids, so this approach of adding more every 6 months is definitely not going to work well in the long term. |
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue DetailsThe current RID graph is incomplete concerning recent Oracle Linux releases. This change, which provides missing RIDs for recent OL versions, will greatly alleviate the burden of maintenance of dotnet on OL by removing of need to patch the source on every update. Associated PRs for dotnet versions supported on OL in respective branches:
|
dotnet/designs#260 has proposal and discussion about the long-term approach for RIDs. |
@omajid what would be the right short term resolution in your opinion? |
For I am okay with these changes hitting 3.1 though. I left some comments/questions at dotnet/corefx#43138 |
|
cc @tmds
Anything that goes to past releases needs to be present in future releases to avoid regressions when folks move forward. I think something is better than nothing. It's not like we're burning resources that would otherwise be spent realizing the new design. Until that new design is implemented we need to unblock folks with the current design.
That makes sense to me, especially since OL derives from rhel. @agocke @vitek-karas thoughts on host changes here? |
That's a good point: we can't add something to the RID graph in 6.x only, it needs to be in
My only concern with adding the RHEL RIDs (assuming they are required for OL to work) is that it's getting us back to needing a new RHEL RID every RHEL minor release (6 months) which we worked hard to move away from. Not having RHEL minor-version RIDs was also a guarantee that a new RHEL minor version wouldn't suddenly be incompatible with .NET because we forgot to update the RID graph. Adding the minor RIDs back makes it possible that we miss out on regressions - because some new piece of code accidentally used the full RHEL version - until the last minute. |
| @@ -148,15 +148,20 @@ | |||
| <RuntimeGroup Include="ol"> | |||
| <Parent>rhel</Parent> | |||
| <Architectures>x64</Architectures> | |||
| <Versions>7;7.0;7.1;7.2;7.3;7.4;7.5;7.6</Versions> | |||
| <Versions>7;7.0;7.1;7.2;7.3;7.4;7.5;7.6;7.7;7.8;7.9;7.10</Versions> | |||
There was a problem hiding this comment.
Red Hat Enterprise Linux 7.9 is the last minor release of RHEL 7.
We shouldn't need to add 7.10 here.
| @@ -216,17 +221,17 @@ | |||
| <RuntimeGroup Include="rhel"> | |||
| <Parent>linux</Parent> | |||
| <Architectures>x64</Architectures> | |||
| <Versions>7;7.0;7.1;7.2;7.3;7.4;7.5;7.6</Versions> | |||
| <Versions>7;7.0;7.1;7.2;7.3;7.4;7.5;7.6;7.7;7.8;7.9;7.10</Versions> | |||
There was a problem hiding this comment.
We we really need to add every minor version here? This is useful only if they are not mutually compatible IMHO. As far as I can see we only track major versions or Centos and Debian.
There was a problem hiding this comment.
The right/long term thing to do is not to add every minor version here. We haven't had to add minor versions for RHEL previously, and this just increases the maintenance/servicing burden.
But since we are now adding OL, we need the parent RHEL versions (is this a strict requirement? Can anyone confirm)
Assuming matching RHEL versions are required, we have two main options:
- Fix everything in the .NET ecosystem (runtime, sdk, build tools) so that it knows that the minor version for Oracle Linux doesn't matter. That's the case for RHEL. Maybe it could be done with
greping forrheland addingolto those conditions? - Add minor versions, expand the RID graph, and deal with keeping it up to date.
There was a problem hiding this comment.
since the ol did not have any minor versions, we can keep doing that as well, right? e.g. just add ol 9?
There was a problem hiding this comment.
Why would we have to fix everything? We could simply say that the RIDs for ol don't include minor version in them (just like we don't include build numbers of Windows in the Windows RIDs). Modify the host such that it will strip the minor version for ol when computing current RID. The rest of the system should not care in that case.
There was a problem hiding this comment.
Why would we have to fix everything?
AFAIK, they are using source-build. Fixing the host will probably be the largest part of the effort, but we will need to update a number of other places like build scripts too.
There was a problem hiding this comment.
I looked through all of .NET 7 source-build sources and after a quick pass, it looks like these files might also need fixups (it's possible I missed something, though):
runtime/eng/native/init-distro-rid.sh
runtime/src/installer/tests/scripts/linux-test/RuntimeInstallation.sh
runtime/src/installer/tests/scripts/linux-test/SdkInstallation.sh
runtime/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Unix.cs
runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtimeGroups.props
runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json
runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtime.compatibility.json
runtime/src/native/corehost/hostmisc/pal.unix.cpp
sdk/src/Cli/Microsoft.DotNet.Cli.Utils/RuntimeEnvironment.cs
sdk/src/Tests/Microsoft.NET.TestFramework/EnvironmentInfo.cs
fsharp/scripts/init-tools.sh
fsharp/scripts/dotnet-install.sh
deployment-tools/eng/native/init-distro-rid.sh
deployment-tools/src/clickonce/native/projects/setup.cmake
deployment-tools/src/installer/Directory.Build.props
diagnostics/eng/init-distro-rid.sh
arcade/src/Microsoft.DotNet.XUnitConsoleRunner/src/common/AssemblyResolution/Microsoft.DotNet.PlatformAbstractions/Native/PlatformApis.cs
There are some test files here too.
There was a problem hiding this comment.
Also, there's a question about what to do in 3.1 and 6.0. Do we fix up host and other files there too? Otherwise, like discussed earlier in this issue, we would have to add minor versions in 6.0 and then add them here too for the sake of compatiblity.
ericstj
added
the
needs-author-action
|
This pull request has been automatically marked |
|
gentle ping, @Mr-Tao |
|
This pull request has been automatically marked |
|
This pull request has been automatically marked |
|
Closing. Please reopen @Mr-Tao if and when you would like to continue. |
|
This pull request has been automatically marked |
|
ghost
locked as resolved and limited conversation to collaborators
The current RID graph is incomplete concerning recent Oracle Linux releases. This change, which provides missing RIDs for recent OL versions, will greatly alleviate the burden of maintenance of dotnet on OL by removing of need to patch the source on every update.
Associated PRs for dotnet versions supported on OL in respective branches:
release/6.0#66684,release/5.0#66683 andrelease/3.1dotnet/corefx#43138.