Address UX issue when building with a Portable Target RID

[ellahathaway]

dotnet/sdk#40843 (comment) highlights that while source-building the VMR with a portable RID implies a portable build, merely naming something doesn't automatically imbue it with the associated properties.

To achieve a functioning portable build, it necessitates a specific setup, including the use of a portable build property and building on the oldest glibc possible, such as CentOS 8 rather than CentOS 9. Without these measures, we might end up with a build that, although labeled as portable, doesn't perform as one.

Two questions then arise:

• Should we automatically enable portable-build mode when a portable RID is specified?
• Should we implement a check to prevent building with a portable RID if the glibc version in use is newer than our baseline?

In general, in answering and addressing these questions, we will improve the UX experience of providing a portable target RID to the build.

[dotnet-issue-labeler]

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

[MichaelSimons]

Related to #2932 and #4413

[MichaelSimons]

[Triage] In discussing this, we feel the best UX is that there is a single gesture to enable portable rids in the build script (e.g. specify a portable RID). If the build system is not capable of producing a portable RID, the build should fail because the resulting assets would not be portable.

[omajid]

@corngood @GGG-KILLER you folks build .NET for Nix in portable mode, right? Will this impact your .NET 9 builds for Nix?

[corngood]

@omajid Thanks for the heads up. We do use portable builds, yeah. Our RID situation is pretty weird:

• we have binaries that are portable across distros, but only because they reference dependencies from /nix/store
• we do this on darwin as well, and would ideally support all platforms in the future

Should we automatically enable portable-build mode when a portable RID is specified?

This probably wouldn't break us.

Should we implement a check to prevent building with a portable RID if the glibc version in use is newer than our baseline?

This would likely break us, and I'd patch it out.

Looking at the existing RIDs, my only thought is to do something similar to musl: linux-nix-x64, darwin-nix-arm64, win-nix-x64 (one day). Portable builds have been working, so I haven't been motivated to try that yet. Even that might be tricky because nixpkgs supports both portable binary sdk/runtime and source-built.

[tmds]

Looking at the existing RIDs, my only thought is to do something similar to musl: linux-nix-x64, darwin-nix-arm64, win-nix-x64 (one day). Portable builds have been working, so I haven't been motivated to try that yet. Even that might be tricky because nixpkgs supports both portable binary sdk/runtime and source-built.

It's fine to build the portable configuration, but you shouldn't use a target rid that is the same as Microsoft's portable rids (cfr dotnet/aspnetcore#54031 (comment)).

Similar discussion for Gentoo using portable rids in this issue: dotnet/runtime#100383.

Should we automatically enable portable-build mode when a portable RID is specified?

This won't help users understand why they shouldn't set the target rid to a portable rid, and stop them from doing it.

we feel the best UX is that there is a single gesture to enable portable rids

I think we should add a separate flag/argument (like runtime's --portablebuild) that enables portable build configuration.

Having such a flag allows to combine the portable build configuration (which is expected to work across a larger range of distros) with a non-portable rid.

When the flag is set (and perhaps some additional conditions) the build could use the portable rid as its target rid.

Should we implement a check to prevent building with a portable RID if the glibc version in use is newer than our baseline?

No. We should try to make it more clear why distro packagers mustn't use portable RIDs for their builds.

[tmds]

merely naming something doesn't automatically imbue it with the associated properties.

This is why I find output-rid a better name than target-rid. target-rid sounds as if it describes the target, rather than naming it.

[tmds]

In dotnet/sdk#41540 we've added an argument to the vmr build script to set the rid. The description should help avoid confusion about what happens when you set the argument.

--rid, --target-rid <value> Overrides the rid that is produced by the build. e.g. alpine.3.18-arm64, fedora.37-x64, freebsd.13-arm64, ubuntu.19.10-x64

cc @am11