Add Oracle Linux support #99728

Mr-Tao · 2024-03-13T22:40:03Z

No description provided.

eng/common/native/init-distro-rid.sh

jkoritzinsky · 2024-03-13T23:06:58Z

src/native/corehost/hostmisc/pal.unix.cpp

@@ -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."));


@richlander @elinor-fung now that we've frozen the RID graph, we shouldn't need these changes, right?

Correct. Host should not care about distro-specific RIDs. This implementation is for legacy .NET versions.

am11 · 2024-03-14T08:02:03Z

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>

Mr-Tao · 2024-03-14T15:40:25Z

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.

This change does not add any RIDs. It is the barest minimum required to build runtime on Oracle Linux.

am11 · 2024-03-14T15:44:00Z

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.

Mr-Tao · 2024-03-14T15:56:31Z

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.

am11 · 2024-03-14T16:32:31Z

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, release/6.0-staging branch can probably accept these sort of changes. @elinor-fung and @agocke maybe able to confirm. You can also keep applying these patches locally to older releases (.NET 6 and 7). Older versions will be out of support later this year so this is naturally becoming a less interesting scenario.

Mr-Tao · 2024-03-14T17:11:33Z

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.

richlander · 2024-03-14T19:59:41Z

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.

@elinor-fung @omajid

omajid · 2024-03-14T20:32:33Z

@tmds do you recall the exact 8.0 behaviour for non-portable RIDs?

tmds · 2024-03-14T21:08:11Z

For .NET 8, non-portable rids are used to identify a source-built .NET made on a distro.
The rid gets baked into the SDK and host at build time.

The vmr uses the init-distro-rid.sh script to determine the default non-portable rid for the distro.
You may want to change it in the dotnet/arcade repo, and then it will get synced to the other repos like this one.

richlander · 2024-03-14T21:30:33Z

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.

tmds · 2024-03-14T21:58:25Z

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.

richlander · 2024-03-14T22:27:50Z

Got it. That sounds like a good approach for the Oracle ecosystem. Yes?

am11 · 2024-03-14T23:26:59Z

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 runs-on: ubuntu-latest)

tmds · 2024-03-15T07:51:17Z

We can simply pass the TargetRid

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 ol.<major> instead of ol.<major>.<minor>.

If you want the change in earlier .NET versions, I think you should apply the patches in your build.

For .NET 8, the patch is trivial (change the vmr init-distro-rid.sh line).
I don't think it's worth looking into for .NET 7 (EOL in May).
For .NET 6, if you think it's worth it (EOL in November), applying the patches will spare upstream maintainers from reviews.

I'll close this PR. If there's a change, it should be in arcade init-distro-rid.sh.

tmds · 2024-03-15T07:55:47Z

@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".

Mr-Tao · 2024-03-15T10:58:05Z

@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.
OL support in .NET 6 official releases is insufficient for people to build it independently.
Given the cadence of releases, it is worth fixing it. I will file a PR for servicing.

am11 · 2024-03-15T11:22:23Z

Yes, the rid is just a name, and it can be set using this property.

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..

A non-portable rid is a namespace for a distro's source-built .NET assets.

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.

tmds · 2024-03-15T11:59:33Z

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.
There is little effort in adding it. PR is dotnet/arcade#14595.

Given the cadence of releases, it is worth fixing it. I will file a PR for servicing.

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.

Mr-Tao · 2024-03-15T12:46:54Z

I'm not sure what versions you mean.

I’m referencing the .NET 6 errata Red Hat is issuing frequently.

tmds · 2024-03-15T13:26:31Z

ack, .NET 6.

We follow RHEL and have already dropped RIDs for minor releases internally.
OL support in .NET 6 official releases is insufficient for people to build it independently.

Are you trying to start building .NET 6 as an Oracle Linux distro maintainer at this time?
Or do you have this working, and is it for the Oracle Linux users to be able to build themselves?

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.

Add Oracle Linux support

088436d

dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 13, 2024

dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Mar 13, 2024

filipnavara reviewed Mar 13, 2024

View reviewed changes

eng/common/native/init-distro-rid.sh Outdated Show resolved Hide resolved

jkoritzinsky reviewed Mar 13, 2024

View reviewed changes

build-analysis bot mentioned this pull request Mar 14, 2024

System.DirectoryServices.Protocols.Tests.BerConverterTests.Decode_Bytes_ReturnsExpected failing on Windows x86 #99725

Closed

Align notation of comparison operators

2750d29

Co-authored-by: Theodore Tsirpanis <teo@tsirpanis.gr>

tmds closed this Mar 15, 2024

Mr-Tao mentioned this pull request Mar 15, 2024

Recognize Oracle Linux dotnet/arcade#14595

Merged

github-actions bot locked and limited conversation to collaborators Apr 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add Oracle Linux support #99728

Add Oracle Linux support #99728

Mr-Tao commented Mar 13, 2024

jkoritzinsky Mar 13, 2024

am11 Mar 14, 2024

am11 commented Mar 14, 2024

Mr-Tao commented Mar 14, 2024

am11 commented Mar 14, 2024

Mr-Tao commented Mar 14, 2024

am11 commented Mar 14, 2024

Mr-Tao commented Mar 14, 2024

richlander commented Mar 14, 2024

omajid commented Mar 14, 2024

tmds commented Mar 14, 2024

richlander commented Mar 14, 2024

tmds commented Mar 14, 2024

richlander commented Mar 14, 2024

am11 commented Mar 14, 2024 •

edited

Loading

tmds commented Mar 15, 2024

tmds commented Mar 15, 2024

Mr-Tao commented Mar 15, 2024

am11 commented Mar 15, 2024

tmds commented Mar 15, 2024

Mr-Tao commented Mar 15, 2024 •

edited

Loading

tmds commented Mar 15, 2024 •

edited

Loading

Add Oracle Linux support #99728

Add Oracle Linux support #99728

Conversation

Mr-Tao commented Mar 13, 2024

jkoritzinsky Mar 13, 2024

Choose a reason for hiding this comment

am11 Mar 14, 2024

Choose a reason for hiding this comment

am11 commented Mar 14, 2024

Mr-Tao commented Mar 14, 2024

am11 commented Mar 14, 2024

Mr-Tao commented Mar 14, 2024

am11 commented Mar 14, 2024

Mr-Tao commented Mar 14, 2024

richlander commented Mar 14, 2024

omajid commented Mar 14, 2024

tmds commented Mar 14, 2024

richlander commented Mar 14, 2024

tmds commented Mar 14, 2024

richlander commented Mar 14, 2024

am11 commented Mar 14, 2024 • edited Loading

tmds commented Mar 15, 2024

tmds commented Mar 15, 2024

Mr-Tao commented Mar 15, 2024

am11 commented Mar 15, 2024

tmds commented Mar 15, 2024

Mr-Tao commented Mar 15, 2024 • edited Loading

tmds commented Mar 15, 2024 • edited Loading

am11 commented Mar 14, 2024 •

edited

Loading

Mr-Tao commented Mar 15, 2024 •

edited

Loading

tmds commented Mar 15, 2024 •

edited

Loading