.NET 8 bundled runtime packs (preview 6)

[tmds]

@dotnet/distro-maintainers, in the upcoming preview 6 the vmr build output will include the .NET Core and ASP.NET Core runtime packs.

These are the source-build equivalents of what Microsoft publishes as https://www.nuget.org/packages/Microsoft.NETCore.App.Runtime.linux-x64 and https://www.nuget.org/packages/Microsoft.AspNetCore.App.Runtime.linux-x64.

They are used when a .NET application is published as self-contained.

By including these packs, it is possible to build a self-contained application that uses binaries you've built from source, rather than binaries that were obtained from nuget.org.

To use these packs, the self-contained application must be published against the non-portable rid, for example:

dotnet publish -r fedora.37-x64 --sc

For this to work, the distro packages for .NET should include the runtime packs which are found at packs/Microsoft.NETCore.App.Runtime.<rid> and packs/Microsoft.AspNetCore.App.Runtime.<rid> in the vmr output.

These files are duplicate files from what is in the shared framework. To avoid bloating the install, you can combine the files with the corresponding shared framework files in a package and use hard links. The vmr output will contain such hard links, but they are easily lost when copying files, so there may be some work in preserving/re-creating them when packaging and installing.

If the packs are not included in the distro .NET packages, the SDK assume they should exist somewhere, go look for them on nuget.org, and fail.

That is the behavior with the preview6 build.
If there is a desire to be able to built without the runtime packs, we can make the feature opt-in.

I've created this discussion to raise awareness the packs are included with preview 6, and for getting your feedback.

cc @ashnaga @MichaelSimons @premun @dsplaisted

[omajid]

The vmr output will contain such hard links, but they are easily lost when copying files, so there may be some work in preserving/re-creating them when packaging and installing

Some feedback after trying this out in CentOS Stream, and RHEL.

Both RHEL 8 and 9 have trouble dealing with hardlinked files. There's some tools that run post-RPM-package-build that apparently haven't been tested with hardlinks. And it turns out they break in a few random ways. It's a bug in RHEL, but there's no immediate fix incoming.

In addition, when hardlinks are packaged into an RPM, something essentially loses track that the files are hardlinked and not copies. When we install the just-built RPMs we get copies of files on disk anyway, losing the benefits disk-space-savings that we would have seen with hardlinks.

[tmds]

You're now trying to use symbolic links instead, right?

.NET follow them while copying.
If there is nothing special that handles symbolic links as part of packs, it should work.

If it works, we can change to use symbolic links instead of hard links.