> 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 | p...@rootwyrm.com > "I didn't break it. I made it a test of common sense." -anon. > _______________________________________________ > freebsd-ports@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
