Hi, Thanks your thoughts! Neal Gompa <ngompa13@xxxxxxxxx> writes: > That's actually a lot better than it was when I helped with dotnet > package review and bootstrap with 3.1. Heh. That's very true! 3.1 had at least two source packages that had to be kept in sync. I think you seemed much happier with the 7.0 review? https://bugzilla.redhat.com/show_bug.cgi?id=2142178 > The main worry I have is how we're going to be able to build dotnet > for a new architecture when nothing exists. RISC-V is the next big > architecture, but the build for that will be difficult. I am working with some folks from IBM on this who have had to build .NET on s390x and ppc64le recently. Just like RISC-V, nothing existed for those architectures before IBM started working on it. IBM have some tools to automate this now. They are working on sharing the tools (and their s390x, ppc64le builds) publicly, but there are some non-technical blockers that prevent them. If/when RISC-V support lands in .NET (eg, minimum of https://github.com/dotnet/runtime/issues/36748), we could use those tools (with hopefully minimal changes) to cross compile .NET for RISC-V. I can ask IBM to prioritize making these tools public. > It would also be good to have packaging guidelines for .NET > applications, since there's a number of server and desktop Linux apps > written in .NET languages that people would want to bring to Fedora. I don't have a great solution for this. There are a few problems here: - .NET applications really, really aren't meant to be built offline. Like other package ecosystems (eg, npm) every .NET application has a ton of dependencies fixed at specific versions. And they are fetched from the internet. There's no clear way to break down the dependency tree so we can start this work. - Unlike ecosystems such as npm where everyone publishes source, .NET packages are binaries without a clear way to go from source -> binary. So even if we could figure out a clear way to slices the dependency tree so we can start building the root packages, it would be a manual process build every package - A subproblem is that lots of libraries only support building on Windows, or through Visual Studio only. We would have to create/port the upstream build scripts. - GUI applications are simply not supported on Linux. .NET has no implementation for this. If you try and use the .NET SDK to build something that uses the GUI APIs, it will simply error out. There's more discussion upstream at https://github.com/dotnet/core/issues/7443 and https://github.com/dotnet/source-build/discussions/2960 As a result of this, I am not sure where to even begin thinking about packaging applications :( Do you have any suggestions on the most important/useful applications that we should look at for prototyping this effort? Omair -- PGP Key: B157A9F0 (http://pgp.mit.edu/) Fingerprint = 9DB5 2F0B FD3E C239 E108 E7BD DF99 7AF8 B157 A9F0 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
