[WIP] Move to standardized RID & OS & ARCH control set

[ViktorHofer]

No description provided.

[ViktorHofer]

@jkoritzinsky I would like your input on the ideal control set (the plan is to eventually upstream this into the Arcade.SDK). Sdk currently passes TargetRid in, in dotnet/sdk YML and the other other properties are inferred from that. I'm going to change that to now always pass TargetOS and TargetArchitecture in. For a portable linux-musl-x64 build, TargetOS=linux-musl and TargetArchitecture=x64, as in the VMR.

But in then noticed that even in the VMR we have to explicitly pass in TargetRid as it is calculated based on the BuildRid: https://github.com/dotnet/dotnet/blob/cf33f78eb2f8f7e593e3511c9c4c2d58c86c729d/eng/pipelines/templates/stages/vmr-verticals.yml#L410-L447 & https://github.com/dotnet/dotnet/blob/cf33f78eb2f8f7e593e3511c9c4c2d58c86c729d/eng/RuntimeIdentifier.props#L52

Does that make sense to you? Would it be sufficient to calculate TargetRid based on TargetOS and TargetArchitecture (if it isn't explicitly provided of course)? Or as a more general question, can we transport enough information with TargetOS+TargetArchitecture in all cases or do we need TargetOS+TargetArchitecture+TargetRid?

[ViktorHofer]

Also thinking about the cases where source-build explicitly builds non-portable RIDs from the same family, i.e. alpine.3.21-x64 and alpine.3.20-x64. This indicates that the TargetOS+TargetArchitecture tuple is only sufficient for portable builds which don't encode the OS version.

[ViktorHofer]

cc @am11 @tmds in case you have opinions. The goal here is to establish a common control set (based on VMR's one) and eventually upstream that to the Arcade.Sdk so that all our core-repos follow that). To avoid issues like #48914 going forward.

[tmds]

I haven't looked at the changes in this PR specifically, so I'm not sure if this is a helpful observation: a common thing to some issues we ran into recently seems to be the lack of a consistent name for the portable rid that corresponds to TargetRid.

[am11]

eventually upstream that to the Arcade.Sdk so that all our core-repos follow that

This is generally a good direction. We discussed about centralizing it across the board some time ago. The seed resolution is still in runtime at the moment https://github.com/dotnet/runtime/blob/c53ccee795268bb2e816f42e4c9e973c50fbd9c3/eng/OSArch.props. So it would be nice to lift this machinery into Arcade.SDK.

To tighten the net, we could add a validation based on file command on Unix and validate that all binaries (https://github.com/dotnet/runtime/blob/c53ccee795268bb2e816f42e4c9e973c50fbd9c3/eng/native/naming.props) produced in the binary SDK tarball belong to the target.