system-libs default [.NET 10]

[tmds]

Currently the vmr defaults to build with bundled libs.

To fix an issue in .NET 9 we switched to use system brotli in dotnet/runtime#107225 and in dotnet/runtime#107166 we're switching back to bundled for .NET 10.

If there is a set of libraries that maintainers will likely prefer to use from the system, it would be nice if the vmr would default to those for "non-portable, source-only" builds.

I assume that brotli is one of those because there was zero objection to switch to the system brotli in dotnet/runtime#107020.

cc @MichaelSimons @omajid @jkotas @dotnet/distro-maintainers

[jkotas]

Does it make more sense to hardcode this default in the dotnet/runtime repo or in the top-level VMR script?

[tmds]

It would be the default value of the argument that is settable on the vmr build script.

For convenience, it would be nice if we make runtime use the same system libs by default when building it non-portable.

[jkotas]

For convenience, it would be nice if we make runtime use the same system libs by default when building it non-portable.

It would mean to hardcode this default in dotnet/runtime repo. If the default is hardcoded in dotnet/runtime repo, is there anything else needed?

[tmds]

No. The runtime can use the default when nothing is set explicitly.

A user will have to look in the runtime sources to know what the default means.

[MichaelSimons]

[Triage] If the default is to use the system-libs, we need to support scenarios where a distro doesn't have all of the required system libs (e.g. there has to be a granular opt out mechanism). I would like more feedback from @dotnet/distro-maintainers on this. What behavior would they like to see?

[mateusrodrigues]

On Ubuntu, the default is to always use archive dependencies whenever possible. Having the VMR default to system libraries then is handy because it would follow our behavior and we would avoid having to maintain a --with-system-libs for all our builds. Also, in a scenario where a new dependency is taken, we don't inadvertently upload a build with a bundled library before either adding a new archive dependency to the package itself or explicitly stating that the bundled version is to be used.

So, IMO I believe that inverting the flag logic from --with-system-libs to --with-bundled-libs would make more sense. We do have corner cases where we use a bundled library because the archive one won't work (such as how we are currently using the bundled libunwind for non-x64 builds), and having an explicit stance for that in the build parameters, instead of the opposite, makes more sense from a package maintenance standpoint, especially since it's much easier to visualize.

Also, I think it would be quite helpful if the help message for the flag in the ./build.sh --help output stated exactly which libraries/entries are supported.