[release/6.0] Microsoft.NETCore.Platforms: support adding rids with '-' in the base part (backport #84413)

[ayakael]

Backport of #84413

Per @tmds

Currently when trying to add a rid like 'linux-musl-x64' the rid is not understood to be base = 'linux-musl', arch = 'x64'.
Instead the parser considers a potential optional qualifier. This causes the rid to be parsed as base = 'linux', arch = 'musl', and qualifier = 'x64'.
We know the rids being added won't have a qualifier. If we take this into account while parsing, we can parse the rid correctly.

Customer impact

#77508 was merged, but its installer counterpart (dotnet/installer#14816) was NAKed due to safety concerns. This revealed a limit with Microsoft.NETCore.Platforms parsing of RID. Thus, build of source-build on linux-musl platforms is currently broken. A few approches on installer side can be implemented as workarounds, but ideally the fix should be on runtime side.

This also unblocks dotnet/installer#13074.

Testing

• unit tests in ci
• manual build of runtime on Alpine Linux when OutputRid=linux-musl-x64 and Source

Risk

Low, there were limited changes in that code between release/6.0 and main.

/cc: @ericst @tmds @omajid

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #84413

Per @tmds

Currently when trying to add a rid like 'linux-musl-x64' the rid is not understood to be base = 'linux-musl', arch = 'x64'.

Instead the parser considers a potential optional qualifier. This causes the rid to be parsed as base = 'linux', arch = 'musl', and qualifier = 'x64'.

We know the rids being added won't have a qualifier. If we take this into account while parsing, we can parse the rid correctly.

Customer impact

#77508 was merged, but its installer counterpart (dotnet/installer#14816) was NAKed due to safety concerns. This revealed a limit with Microsoft.NETCore.Platforms parsing of RID. Thus, build of source-build on linux-musl platforms is currently broken. A few approches on installer side can be implemented as workarounds, but ideally the fix should be on runtime side.

This also unblocks dotnet/installer#13074.

Testing

• unit tests in ci
• manual build of runtime on Alpine Linux when OutputRid=linux-musl-x64 and Source

Risk

Low, there were limited changes in that code between release/6.0 and main.

/cc: @ericst @tmds @omajid

Author:	ayakael
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[tmds]

#77508 was merged, but its installer counterpart (dotnet/installer#14816) was NAKed due to safety concerns.

For some more context:

This change set had two goals: eliminate portable build of runtime (in installer), and update the runtime graph with the target rid (in runtime).

Because only the runtime part got merged, we're now in a situation where the portable build ensures the target rid (which is the portable rid) is in the graph.
And, for the linux-musl portable rid, there is an issue due to the - in its name. This PR is fixing that issue.

I think @ayakael has been patching his builds to work around this issue.

And the issue has now surfaced again with @omajid working on adding a source-build 6.0 CI leg for Alpine: dotnet/installer#13074.

[carlossanlop]

Today is code complete for the May Release. If we want this fix to get included in that release, please get the PR ready to merge before 4pm PT today:

• Get a Tactics approval. @wfurt can you please send the email and champion this? tell-mode.
• Confirm the CI failures are unrelated to this change. Edit: Failures unrelated.
• Get a sign-off from an area owner. @wfurt
• The change affects the Microsoft.NETCore.Platforms OOB package. Make sure the required OOB package authoring changes are included in the PR. Not needed for June Release if this PR gets merged too (it already includes the OOB changes): Add Ubuntu 22.10 kinetic kudu RIDs for .NET 6 #84983

Otherwise, this will have to go into the June Release.

[carlossanlop]

I'm treating this as tell-mode since the affected cs file is a build task, so not customer facing. I notified Tactics anyway just so they were informed.