Date: Mon, 22 Jul 2019 18:45:56 -0400 From: "Phillip R. Jaenke" <prj@rootwyrm.com> To: freebsd-ports@FreeBSD.org Subject: Question for users and consumers of lang/mono and NuGet Message-ID: <4017ca2e-0ada-9891-2e5a-350e7cf5fdf5@rootwyrm.com>
next in thread | raw e-mail | index | archive | help
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. 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@rootwyrm.com "I didn't break it. I made it a test of common sense." -anon.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4017ca2e-0ada-9891-2e5a-350e7cf5fdf5>