Fwd: Are there architectural limitation for packages in ports?
Though according to: https://www.andrewhoefling.com/Blog/Post/net-5-and-the-future-of-net-framework-and-net-core >.NET 5 and .NET Standard >What is the life of .NET Standard and will it be going away? >.NET Standard is not going anywhere as far as I understand and will be very >important to the success of .NET 5 as the code-base get's unified. With .NET 5 >the idea is to create a shared Base Class Library (BCL) that will have >different runtime virtual machines. >MonoVM >CoreCLR >The idea is you can have drop-in replacements with the different runtime VMs >but it will all be 1 .NET. Therefore it may be not so important to have specifically Microsoft VM since if it is fully compatible with community's Mono VM which is already present in OpenBSD ports?
Re: Are there architectural limitation for packages in ports?
Another question, are we going to see DotNet Core in OpenBSD? Something like: https://data.gpo.zugaina.org/lanodanOverlay/dev-dotnet/dotnetcore-sdk/dotnetcore-sdk-3.0.100.ebuild
Are there architectural limitation for packages in ports?
For example if we look at mono package on Gentoo: https://packages.gentoo.org/packages/dev-lang/mono We will see there are missing ports for alpha, hppa, ia64 and sparc, actually I might be interested only in sparc among them. On the other hand are there any similar limitations for the: https://openports.se/lang/mono if it is built on OpenBSD
