[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: getting pinta updated in Debian



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

FOSS Hacker             meebey@meebey.net      https://www.meebey.net/
Debian Developer        meebey@debian.org      https://www.debian.org/
GNOME Foundation Member mmmbauer@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 <sshaw@decriptor.com> wrote:
On Thu, Mar 3, 2022 at 12:47 PM Gunnar Wolf <gwolf@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


Reply to: