It's important to note that as far as I know, nobody on FPC is particularly a dotnet expert; the guidelines we have were written by the people doing the packaging work. So we probably can't usefully answer specific questions about dotnet esoterica, though of course we would accept pull requests to alter the current guidelines if the community of packagers actually working in the space agree.

However, "self-contained" to me carries a connotation of something similar to static linking, and based on the general principles underlying most of the distribution, I would suggest that such things be avoided if feasible (and this is codified elsewhere in the guidelines more generally). So the fundamental question here, I think, is: If there's a bug fixed in the runtime, would every "self-contained executable" need to be rebuilt to pick that up? And would that answer differ if instead the packages depended on the runtime? The one that requires less rebuilding for security and bugfixes is, if nothing else differs, going to be the suggested option.

Thanks. I had a go creating a package https://copr.fedorainfracloud.org/coprs/matthickford/git-credential-manager/ following the Copr tutorial. Feedback welcome -- I developed on Debian without a Fedora install to test. https://github.com/GitCredentialManager/git-credential-manager/issues/816

It would be interesting to inspect other packages depending on dotnet-runtime-6.0 to see their rpm specs -- do you know where I see that?

Here's a link to my rpm spec https://github.com/hickford/git-credential-manager/blob/rpm/git-credential-manager.spec

A problem is that the rpm build requires internet access for the dotnet restore step. Advice from a .NET expert welcome.

Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet.

Hi. Speaking as a member of the DotNet SIG here.

In particular, should .NET application packages depend on package dotnet-runtime-* ? Or hold a self-contained executable?

Unless there's a very good reason, framework-dependent applications should be preferred by default. Self-contained applications are effectively statically linked and bundle everything (including the runtime and all other .NET libraries) into the application. Aside from the security and bugfix issues that @tibbs touched on, building in other configurations requires an even larger set of dependencies from the internet, or it requires .NET in a build configuration (eg, linux-x64) that we simply don't have in Fedora.

A problem is that the rpm build requires internet access for the dotnet restore step.

Yes. I don't have a good solution here. Fedora was one of the earlier distributions that packaged .NET and the .NET Linux-distribution ecosystem is so new that we haven't really figured out how to handle building other .NET applications.

I am not aware of packaged applications in Fedora that are using .NET.

It's possible we need to walk down the dependency graph (recursively) of your application and look at all those dependencies and then try and build/package all of them in Fedora. That's what I think other language ecosystem stacks end up doing. It's also extremely hard and time-consuming. The Java folks have been having a tough time maintaining the entire stack in Fedora too: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/4EHBACT4I263R4QF75HB3DUJWWANGHAS/

Just FYI, because you linked my mailing list post: I'm not sure Java is a good example here. It's an ancient ecosystem with an ethos around shipping pre-built bytecode that just never has fit well with how linux distributions work. Other, more modern ecosystems (Python, Ruby, even Rust and Go, in most cases) are more friendly towards Linux distributions. Application dependencies are packaged as separate packages, and with good tools, that's a manageable effort - compared to Java, where the ecosystem was actively trying to kill you when you tried to do that.

I mentioned Java because I think it's the closest ecosystem (at least right now) in practice to .NET. As far as I know, just like Java, the focus with .NET is to distribute packaged binaries (bytecode, but sometimes even Windows libraries) in the Java package repositories. .NET (Core) may be new, but a large part of the community/conventions go back to the 20-year-old proprietary .NET Framework that was only available on Windows. Just like Java, there's little formal support for third parties (including Linux distributions) to rebuild a piece of code to produce something similar to packaged binaries that the author produced and published to the Java package repositories. Tools that I think exist for Python, Ruby, Rust and Go that make packaging easier don't exit at this point for .NET.

Apologies if I mis-characterized or downplayed the heroic efforts of the folks trying to keep the Java stack up to date in Fedora.

I brought this up with upstream .NET folks here: https://github.com/dotnet/source-build/discussions/2960

The .NET folks think there are a number of challenges here that do need to be addressed on the .NET side (whether through tools, ecosystem, conventions or something else) before it becomes really practical for distros to start packaging .NET packaging.