Re: getting pinta updated in Debian
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: