Hello Stephen, Hello Jo! thanks for sharing your thoughts on the tricky dotnet package ecosystem which I can fully relate to. In the Debian Mono Group we discussed these many times on the available options how we can overcome these new packaging challenges.
The problem indeed starts with a shift of how code is distributed. Developers no longer publish source archives (.zip, .tar.gz, etc) but they publish binary packages into a language specific package format and ecosystem (e.g. nuget, pip, etc). Where the users of their code then use nuget to consume these. The best solution we could find is an approach that Debian Perl has taken with CPAN. So you would basically assist creating debian packages from nuget packages with Debian tools (to be developed). For Perl there is dh-make-perl [0] doing exactly this. So this shift in the ecosystem is solvable but it will take some weeks of work to get there. [0]: https://packages.debian.org/sid/dh-make-perl Best regards, Mirco Bauer Chief InfoSec Officer mirco.ba...@eqonex.com https://group.eqonex.com/ FOSS Hacker mee...@meebey.net https://www.meebey.net/ Debian Developer mee...@debian.org https://www.debian.org/ GNOME Foundation Member mmmba...@gnome.org https://www.gnome.org/ .NET Foundation Advisory Council Member https://www.dotnetfoundation.org/ PGP-Key ID 0x7127E5ABEEF946C8 https://meebey.net/pubkey.asc On Fri, Mar 4, 2022 at 5:24 AM Stephen Shaw <ss...@decriptor.com> wrote: > On Thu, Mar 3, 2022 at 12:47 PM Gunnar Wolf <gw...@debian.org> wrote: > > > > Timotheus Pokorra dijo [Wed, Mar 02, 2022 at 10:35:36PM +0100]: > > > Hello Mike, > > > > > > I have some experience with Mono packaging in Fedora. > > > I know of the dotnet SIG in Fedora. They made a massive effort, > involving > > > Microsoft employees, to get dotnet core built according to the Fedora > rules > > > (build from source, not using external files, etc). > > > (...) > > > It is really difficult to package dotnet packages, because of all the > nuget > > > dependancies. We have not figured that out for Fedora. Or did not have > the > > > volunteers yet to do that. > > > > > > Alternatives to dotnet: Mono, dotgnu > > > https://www.gnu.org/software/dotgnu/ > > > "As of December 2012, the DotGNU project has been decommissioned." > > > > > > Mono: it is the alternative to .NET Framework, which Microsoft will > support > > > for many years to come. But the new stuff is happening in dotnet, so > > > projects like Pinta are moving from Mono to dotnet. > > > > Uff... .NET -- A reimplementation of the "write once, debug > > everywhere" fiasco :-( > ^^ Seems like a horribly useless and uninformed clickbait comment.... > > > Warning: I'm going to brain dump a bunch of random thoughts :) > > Mono is actually now part of dotnet: > https://github.com/dotnet/runtime/tree/main/src/mono > dotnet provides two different runtimes. coreclr and monovm both of > which are largely xplat. > The traditional .NET Framework and Mono are going away in favor of > dotnet. Still largely the same runtime, base class libraries, etc that > .NET developers are used to + all the new features and it's continued > evolution, etc > > tl;dr; from my perspective.... > I've felt like this has been a growing problem with how Linux does > packaging, right or wrong doesn't matter. The fact still remains that > this'll continually become more challenging and/or impossible problem > at some point. Most, if not all, of the current popular programming > languages have some sort of packaging system: > C#, nuget > java, maven > ruby, rubygems > python, pip > node.js, npm > php, pakcagist > js, bower > > to name a few. > > The current approach is to rebuild ever language from source, but most > devs don't want to re-implement a whole bunch of functionality they > can get with the push of a button by adding some "package". As > programs get more complex there are more libraries being written, > shared, and included. Unless you can completely automate the building > of every package this breaks down really fast. > > Maybe its time to re-evaluate this system? > Could we provide some kind of sandbox that builds these projects and > allows for an internet connection to import all of the "packages"? Is > it possible to ensure that the packages are exclusively pulled from > "authorized" sources? > > Cheers, > Stephen > >
