Add some upcoming distro RIDs#34088
Conversation
|
Anyone willing to review this? |
|
Historically, we've avoided adding things into the RID graph until there's some evidence that the next version is already named (think of it as "everyone was surprised at Windows 10 being 10", but also SUSE's rebrand/reset). I think I'm willing to handwave and say that someone from RedHat pushing for things RedHat has a lot of influence over (if not outright control over) is acceptable. This currently doesn't build, do to reporting a dependency on a node that doesn't exist. I don't have strong opinions on whether we should add a vacuous entry for rhel7-arm64 or split the definition of CentOS inheritance. @ericstj? |
If it makes you more comfortable, I can remove this part of the patch and just deal with |
With 32 & 33 Fedora still in future, adding 34 seems quite far given @bartonjs guidance. 'rhel7-arm64' seems fine since |
src/libraries/pkg/Microsoft.NETCore.Platforms/runtimeGroups.props
Outdated
Show resolved
Hide resolved
Just follow consistent patterns in this file for |
|
As an additional piece of context: please note that Fedora (32 and later) includes .NET Core SDK 3.1 as a standard distro package. You can install
In practice, they are not far at all. According to the schedule, 32 is "done" development. 33 is in development. At some point in the future, that will be forked to Fedora 34. When that fork is created, the SDK build in Fedora already needs to know about that RID. Or the SDK in Fedora 34 will stop working. I can definitely wait a few months, but we need to make this change (in isolation in Fedora, or here in the main repositories) to make this RID available before Fedora 34 starts development and the
Nope, there's nothing there that I know of. As I linked to earlier, right now there's only discussions going on in the Fedora community on how to create something that might eventually be called RHEL 9. FWIW, I think RHEL 9 is much further off than Fedora 34. |
This adds some RIDs that we know are current/upcoming: - Fedora 33 is in development, and the version after this is most likely going to be Fedora 34. Adding this RID now, so we can get this RID in all current releases when it comes time to build on Fedora 34 - RHEL has generally committed to doing a major release every 3 years. With RHEL 8 released in 2019, RHEL 9 is under development. There's even a plan on how to create that from Fedora here: https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose - If there's a RHEL 9, there will most likely be an equivalent CentOS 9. Lets add that too. - CentOS 7 has an aarch64 port. As does CentOS 8.
85476ae to
01fb572
Compare
|
@ericstj Thanks, fixed. |
Fedora 34 is currently in development. Building .NET Core 3.1 there (via
source-build) fails because the runtime id `fedora.34` is unknown:
error NETSDK1083: The specified RuntimeIdentifier 'fedora.34-x64' is not recognized.
This is a partial backport of
dotnet/runtime#34088
Fedora 34 is currently in development. Building .NET Core 3.1 there (via
source-build) fails because the runtime id `fedora.34` is unknown:
error NETSDK1083: The specified RuntimeIdentifier 'fedora.34-x64' is not recognized.
This is a partial backport of
dotnet/runtime#34088
This adds some RIDs that we know are current/upcoming:
Fedora 33 is in development, and the version after this is most likely going to be Fedora 34. Adding this RID now, so we can get this RID in all current releases when it comes time to build on Fedora 34
RHEL has generally committed to doing a major release every 3 years. With RHEL 8 released in 2019, RHEL 9 is under development. There's even a plan on how to create that from Fedora here: https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose. Also called out here
If there's a RHEL 9, there will most likely be an equivalent CentOS 9. Lets add that too.
CentOS 7 has an arm64 (aka aarch64) port. As does CentOS 8.
One question: I noticed that this creates an RID graph with an entry for
rhel.7-arm64. This RID doesn't already exist in the graph. Is that a bad thing? Should I split out the CentOS entries? Should I add an RID forrhel.7-arm64, which isn't really "supported", but was a product at one point?