On Thu, Jun 1, 2023 at 11:05 AM Omair Majid <omajid@xxxxxxxxxx> wrote: > > 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. > Some progress on RISC-V has been made: https://github.com/dotnet/runtime/issues/84834 Hopefully some more will be done soon. :/ > > 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 > I'm a bit less concerned about the fact that Microsoft has eliminated MonoForms and never provided a WPF/WinUI implementation. It's annoying, but that's not the problem to solve right now. Being able to ship things like Avalonia would at least reduce that barrier for GUI app dev in .NET: https://avaloniaui.net/ > 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? > The main one on my radar right now is Jellyfin, but I also recently saw a GNOME Circle app in C# called TubeConverter. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
