-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Oracle Linux support #99728
Add Oracle Linux support #99728
Conversation
@@ -767,6 +767,7 @@ pal::string_t normalize_linux_rid(pal::string_t rid) | |||
pal::string_t rhelPrefix(_X("rhel.")); | |||
pal::string_t alpinePrefix(_X("alpine.")); | |||
pal::string_t rockyPrefix(_X("rocky.")); | |||
pal::string_t olPrefix(_X("ol.")); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@richlander @elinor-fung now that we've frozen the RID graph, we shouldn't need these changes, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. Host should not care about distro-specific RIDs. This implementation is for legacy .NET versions.
Duplicate of #81115 (comment). As @agocke wrote, we are not going to feed the entire database of (600+) linux distros in runtime. The new way is to use source build with your preferred RID tag without changing the frozen code. |
Co-authored-by: Theodore Tsirpanis <teo@tsirpanis.gr>
This change does not add any RIDs. It is the barest minimum required to build runtime on Oracle Linux. |
We don't want to add distros related info anywhere in the repo. You can build it just fine with source-build using whatever RID you please. As far as the runtime is concerned, it is just linux. |
Should I create a PR against individual release/x branches instead? There are ol RIDs in all dotnet releases, but the support is broken, so they do not build. |
You can download Microsoft binaries (from http://dot.net/core) and run it on Oracle Linux (or any distro for that matter). That is always an option. .NET 8 should be built just fine with source-build (VMR: https://github.com/dotnet/dotnet) setting the desired RID for the entire suite. If .NET 8 build is breaking, please file an issue with steps to repro etc. and lets figure out the solutions which will scale long-term. (we have a CI leg exercising imaginary "banana linux" to make sure non-portable builds work without hardcoding names). Was it building on the older versions and something broke recently, or it never built? We normally don't add new platform support in older releases; but since OL is already in (now-)obsoleted RID graph, |
It’s been broken since the OL minor versions that are not already present in the RID graph were released. I’ve been trying to get the fix merged for eternity, during which time the support for new RHEL-derived distros was merged, and RID policy has shifted. When I tried to get the support merged into release branches, I was told that it needed to go to the main first. |
Are you trying update/fix all (supported) .NET versions or just .NET 8? I know that the host has some logic for specific distros. It looks like this is what this PR is changing. I cannot remember what our final plan was for that with .NET 8. |
@tmds do you recall the exact 8.0 behaviour for non-portable RIDs? |
For .NET 8, non-portable rids are used to identify a source-built .NET made on a distro. The vmr uses the |
I think the specific question was related to the RID roll-forward behavior for OSes that have compatible dot releases, like RHEL. AFAIK, this behavior is/was in the host. |
Part of the simplifications we made to the rid-handing in .NET 8 is based on no longer supporting picking between different assets identified by non-portable rids. This means we also no longer need to express the compatibility between different non-portable rids. |
Got it. That sounds like a good approach for the Oracle ecosystem. Yes? |
We can simply pass the TargetRid from VMR without continuously updating these frozen parts. This is a script for Oracle Linux: $ git clone https://github.com/dotnet/dotnet vmr --single-branch --depth 1 --branch v8.0.3
$ docker run --rm -w /vmr -v$(pwd)/vmr:/vmr amd64/oraclelinux:9 sh -c \
'dnf install --setopt tsflags=nodocs --refresh -y automake clang cmake curl findutils git krb5-devel libicu-devel lldb-devel llvm lttng-ust openssl-devel python3 tar zlib-devel;
dnf --enablerepo=ol9_codeready_builder install lttng-ust-devel;
./prep.sh;
./build.sh --clean-while-building -- -p:TargetRid=ol.9.1-x64' took ~65 mins on GitHub Actions (with |
Yes, the rid is just a name, and it can be set using this property. @Mr-Tao I don't think anyone will object if you add Oracle Linux to this line: https://github.com/dotnet/arcade/blob/4e73daf131ef02e8264b0d3e850c4bdafe6e02b6/eng/common/native/init-distro-rid.sh#L23. When that rippled down, all the repos will consistently name it using If you want the change in earlier .NET versions, I think you should apply the patches in your build.
I'll close this PR. If there's a change, it should be in arcade |
@richlander @omajid to summarize earlier discussion about non-portable rids in .NET 8+: A non-portable rid is a namespace for a distro's source-built .NET assets. The other use-cases we had pre-.NET 8 are "legacy". |
@richlander, I want to fix all supported versions. I’ve started with the main because, in the past, I was asked to commit to the main before making a PR for servicing. @tmds We follow RHEL and have already dropped RIDs for minor releases internally. |
Yup, you and others have done great job streamlining those properties end-to-end and I was suggesting that we should invest in that direction simply because it scales well. Broadly speaking, anyone is able to build .NET using RID of their choosing and feel free to change the RID format at later point without modifying the sources. We do not need to modify these internal scripts to achieve the auto-detection of distro ID, which is an artifact of old NET Core versions (when non-portable was the only option). The downside of accepting one of these is that these kind of changes will never stop and we are back to feeding distro lists in code..
Exactly, preferred namespace (or tag?) is something best specified at the top VMR level. Maybe we should make it a required parameter in VMR's main build script and remove this auto distro detection altogether. |
Until some change like this happens, I think we should treat it the same as Rocky and RHEL in the script.
I'm not sure what versions you mean. Depending on the work needed on your end, you may want to check up-front if the maintainers will accept the change for those versions. |
I’m referencing the .NET 6 errata Red Hat is issuing frequently. |
ack, .NET 6.
Are you trying to start building .NET 6 as an Oracle Linux distro maintainer at this time? I assume for the latter, the Oracle Linux users should be able to start from the source rpms created by the Oracle Linux distro maintainers? For the first, either patches go into rpms or they go upstream. I don't think upstream has a particular interest in these patches, so depending on the work involved, you may want to check up-front if the maintainers will accept them. |
No description provided.