Skip to content
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 Fedora 36 to the RID graph #57832

Merged
merged 2 commits into from
Aug 23, 2021
Merged

Add Fedora 36 to the RID graph #57832

merged 2 commits into from
Aug 23, 2021

Conversation

omajid
Copy link
Member

@omajid omajid commented Aug 20, 2021

Fedora 36 is under development:

$ podman run -it registry.fedoraproject.org/fedora:rawhide /bin/cat /etc/os-release
NAME="Fedora Linux"
VERSION="36 (Container Image Prerelease)"
ID=fedora
VERSION_ID=36
VERSION_CODENAME=""
PLATFORM_ID="platform:f36"
PRETTY_NAME="Fedora Linux 36 (Container Image Prerelease)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:36"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Container Image"
VARIANT_ID=container

I couldn't get the changes runtime.json to show up until I built with a customtarget. I updated readme.md with that extra information too.

Fedora 36 is under development:

    $ podman run -it registry.fedoraproject.org/fedora:rawhide /bin/cat /etc/os-release
    NAME="Fedora Linux"
    VERSION="36 (Container Image Prerelease)"
    ID=fedora
    VERSION_ID=36
    VERSION_CODENAME=""
    PLATFORM_ID="platform:f36"
    PRETTY_NAME="Fedora Linux 36 (Container Image Prerelease)"
    ANSI_COLOR="0;38;2;60;110;180"
    LOGO=fedora-logo-icon
    CPE_NAME="cpe:/o:fedoraproject:fedora:36"
    HOME_URL="https://fedoraproject.org/"
    DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
    SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    VARIANT="Container Image"
    VARIANT_ID=container

I couldn't get the changes runtime.json to show up until I built with a custom
target. I updated readme.md with that extra information too.
@dotnet-issue-labeler
Copy link

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

@omajid
Copy link
Member Author

omajid commented Aug 20, 2021

Hey @ViktorHofer am I doing something wrong with /t:UpdateRuntimeJson? Should it have worked out of the box?

@ViktorHofer
Copy link
Member

Hey @ViktorHofer am I doing something wrong with /t:UpdateRuntimeJson? Should it have worked out of the box?

I don't know what UpdateRuntimeJson is exactly doing without looking into its sources. I think @ericstj should be able to answer.

omajid added a commit to omajid/dotnet-runtime that referenced this pull request Aug 20, 2021
Backport of dotnet#57832

Fedora 36 is under development:

    $ podman run -it registry.fedoraproject.org/fedora:rawhide /bin/cat /etc/os-release
    NAME="Fedora Linux"
    VERSION="36 (Container Image Prerelease)"
    ID=fedora
    VERSION_ID=36
    VERSION_CODENAME=""
    PLATFORM_ID="platform:f36"
    PRETTY_NAME="Fedora Linux 36 (Container Image Prerelease)"
    ANSI_COLOR="0;38;2;60;110;180"
    LOGO=fedora-logo-icon
    CPE_NAME="cpe:/o:fedoraproject:fedora:36"
    HOME_URL="https://fedoraproject.org/"
    DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
    SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    VARIANT="Container Image"
    VARIANT_ID=container
@ghost ghost added the community-contribution Indicates that the PR has been added by a community member label Aug 20, 2021
@ericstj
Copy link
Member

ericstj commented Aug 20, 2021

am I doing something wrong with /t:UpdateRuntimeJson? Should it have worked out of the box?

It would have when running pack. If you aren't packing you can run the target directly. I think the docs are unclear about this since they say "rebuild the project" which made sense when it was a dedicated pkgproj but is no longer the best wording now that it's a CSProj. I'm fine with the update you made to the docs.

ViktorHofer pushed a commit that referenced this pull request Aug 23, 2021
Backport of #57832

Fedora 36 is under development:

    $ podman run -it registry.fedoraproject.org/fedora:rawhide /bin/cat /etc/os-release
    NAME="Fedora Linux"
    VERSION="36 (Container Image Prerelease)"
    ID=fedora
    VERSION_ID=36
    VERSION_CODENAME=""
    PLATFORM_ID="platform:f36"
    PRETTY_NAME="Fedora Linux 36 (Container Image Prerelease)"
    ANSI_COLOR="0;38;2;60;110;180"
    LOGO=fedora-logo-icon
    CPE_NAME="cpe:/o:fedoraproject:fedora:36"
    HOME_URL="https://fedoraproject.org/"
    DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/"
    SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
    BUG_REPORT_URL="https://bugzilla.redhat.com/"
    REDHAT_BUGZILLA_PRODUCT="Fedora"
    REDHAT_BUGZILLA_PRODUCT_VERSION=rawhide
    REDHAT_SUPPORT_PRODUCT="Fedora"
    REDHAT_SUPPORT_PRODUCT_VERSION=rawhide
    PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
    VARIANT="Container Image"
    VARIANT_ID=container
@ViktorHofer
Copy link
Member

Merging as the previous run was successful and the recent commit just update a docs file.

Thanks a lot @omajid

@ViktorHofer ViktorHofer merged commit 185ae3b into dotnet:main Aug 23, 2021
@tmds
Copy link
Member

tmds commented Aug 24, 2021

@ericstj @ViktorHofer I thought, thanks to #50818, we no longer have to make these changes?

@ViktorHofer
Copy link
Member

You likely want what's proposed in NuGet/Home#5862 as well. #50818 helps with source build as you can define a new RID via a variable but I don't see how this would help when not source building.

@tmds
Copy link
Member

tmds commented Aug 25, 2021

#50818 helps with source build

Yes.

I don't see how this would help when not source building.

I'm not aware of issues.
If there are, probably they can be addressed to make this type change also unnecessary for non-source build.

@tmds
Copy link
Member

tmds commented Aug 26, 2021

I changed my /etc/os-release to pretend it's the non-existing Fedora 40.
I then built clr+libs+libs.tests and ran tests. This worked fine.

@ViktorHofer @ericstj unless we know why we need them, can we stop adding new distro versions RIDs?

@ViktorHofer
Copy link
Member

How would you add fedora.40 specific package assets that shouldn't include to fedora.39 without having rids per version?

@tmds
Copy link
Member

tmds commented Aug 27, 2021

How would you add fedora.40 specific package assets that shouldn't include to fedora.39 without having rids per version?

In practice, we've seen this is not scalable and it can cause applications to fail when a system is upgraded from one version to the next.

Instead, I'd add assets for all supported Fedora versions, and pick the most appropriate at runtime (e.g. using NativeLibrary).

For example LibGit2Sharp does this: https://github.com/libgit2/libgit2sharp/blob/6329bea6d315f563d7107982bccbea4325947808/LibGit2Sharp/Core/NativeMethods.cs#L149-L151.

@ViktorHofer
Copy link
Member

In practice, we've seen this is not scalable and it can cause applications to fail when a system is upgraded from one version to the next.

My assumption is that the current design isn't scalable because of the issues listed in NuGet/Home#5862.

cc @ericstj for his opinion

@ericstj
Copy link
Member

ericstj commented Sep 2, 2021

#50818 helps folks avoid source changes when building dotnet/runtime on new distros. It doesn't eliminate the need to have discrete RIDs listed in the RID graph in order to support those new distros at runtime/design-time. The Host, NuGet, and SDK still depend on that. I'd love to see us eliminate that in v.Next. cc @richlander

@richlander
Copy link
Member

My most frequent experience with this is with Alpine, which ships frequently. We're almost always waiting on new RIDs to release a new Alpine. That makes little sense to me.

I think the order should be (using existing versions as examples):

  • Release new .NET 5 container images for Alpine 3.14, ASAP.
  • Declare somehow that Alpine 3.14 is equivalent to Alpine 3.13 (which has an existing RID)
  • This means we don't have to wait on ANY product changes.
  • At our convenience (within 2 months), add Alpine 3.14 to the RID graph so that people can explicitly target it.

Perhaps we could do this today, but it's not what we do.

/cc @mthalman

@tmds
Copy link
Member

tmds commented Sep 3, 2021

At our convenience (within 2 months), add Alpine 3.14 to the RID graph so that people can explicitly target it.

For distros that move fast like Fedora and Alpine, we continuously need to upgrade the rid graph.
As I mentioned earlier, it is not only a scalability issue for us updating the graph, but also the same scalability issue exists for users targeting these individual rids.

That makes it impractical to use these rids, and a preferable solution is to do assets selection at runtime using NativeLibrary, RuntimeInformation.RuntimeIdentifier, ...

It may still be interesting to target the parent rid (e.g. fedora-x64).
We can extend the Host, NuGet, and SDK, ... so they have some logic like #50818.
That means when .NET runs on the unknown alpine.3.14-x64, it will still consider alpine-x64 assets.

@richlander @ericstj your thoughts?

@ghost ghost locked as resolved and limited conversation to collaborators Oct 3, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Host community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants