Question for users and consumers of lang/mono and NuGet

[driesm.michiels at gmail.com]

> All;
> 
> Since I work with Mono extensively at home and at work, I've been working
> closely with the Mono Project folks to get things compiling and running
much
> more cleanly on FreeBSD. And I'm very happy to say that excellent progress
> has been made including a number of patches upstream.
> 
> The Mono Project has just released the latest stable, 6.0.0.313, which is
a
> major upgrade. Not all Mono 5.x projects may work on it, they need tested,
> etcetera. But 6.0.0.313 needs only two patches already committed upstream
> and one corefx patch. The Mono Project honestly seems pretty keen on
> having FreeBSD as a 'first class' citizen, and is even working on adding
> FreeBSD to their CI pipeline.

Just my 2 cents; this is awesome news! 
Many will be happy about a new mono version getting in the tree.

> 
> But at the same time, lang/mono has basically languished on 5.10, which
has
> numerous known bugs and performance issues. These have been addressed
> in later versions, which also compile MUCH easier. Add to that,
> Uses/mono.mk is still using obsoleted repositories and setups that haven't
> been current in more than a year now.
> 
> Simply put, leaving lang/mono 'as-is' should not be viewed as a realistic
> option. Yes, it's still 'supported' upstream 'officially.' But it's really
not, and
> it's really a problem. That said, it's also not necessarily feasible to
just
> replace lang/mono with 5.18 stable as this may break some consumers.
> I have already completed the work to get Mono versions 5.14 through 5.20
> and 6.0.0.313 building and passing all Mono tests on FreeBSD. These are
all
> ready to go. And not solely on amd64; most are ready to go on aarch64, and
> 5.18+ should be able to do ppc64.
> 
> The question therefore, is one of versions and layout. Mono does NOT have
> a DEFAULT_VERSIONS and to be quite honest, adding one to the existing
> infrastructure is beyond my abilities. (Believe me, I tried.) I also do
not know
> what out there is using the existing NuGet stuff in Uses/mono.mk. So I
don't
> know if it's safe to just rip it all out.
> 
> My personal preference here would be to add DEFAULT_VERSIONS+=mono,
> rename lang/mono to mono5.10, and add lang/mono5.[16,18,20] and
> lang/mono6[.0,-devel]. This isn't something I've had any luck with, and I
> never heard back from mono@ when I reached out for guidance and
> assistance there. So I would need someone to help me with adding that
> support. If someone can give me a DEFAULT_VERSIONS switch, I can carry it
> the rest of the way, no problem.
> Option two is to leave lang/mono to rot and to create new ports for each
> version, and rely on the user or consumer to select the correct version.
> This however, creates a problem in that now net-p2p/sonarr might want
> 5.18 and net-p2p/radarr wants 5.20, and both versions of Mono require
files
> be installed in the same locations. So obviously, it's not the preferred
or
> optimal solution. (Generally speaking anything good with
> 5.18 will run with 5.20 and vice versa since it's more about the .NET
level, but
> there are bugs and known issues a given app may be impacted by.)
> 
> So if your port or you use mono or NuGet, I would very much appreciate
your
> feedback here before I submit a raft of patches that might have impacts to
> your stuff. ;) But I most definitely would appreciate any feedback or
guidance
> folks could provide here so I can get these updates into the tree as soon
as
> possible.
> 
> Thanks in advance!
> 
> -Phillip R. Jaenke | prj at rootwyrm.com
>  "I didn't break it. I made it a test of common sense." -anon.
> _______________________________________________
> freebsd-ports at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"