mirror of
https://github.com/jellyfin/jellyfin.git
synced 2026-05-04 18:09:12 +03:00
Remove Mono support #54
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @andrewrabert on GitHub (Dec 12, 2018).
Now that we're building with .NET Core, we should deprecate and remove all Mono-related code. It's more to maintain and test.
@andrewrabert commented on GitHub (Dec 12, 2018):
@joshuaboniface Thoughts?
@joshuaboniface commented on GitHub (Dec 12, 2018):
Agreed, the Deb packages work well without Mono so we should clean up whatever we can.
@Camotoy commented on GitHub (Dec 12, 2018):
If I'm correct, .NET Core doesn't fully support FreeBSD (see https://github.com/dotnet/corefx/issues/1626). How will this affect future FreeBSD releases?
@joshuaboniface commented on GitHub (Dec 12, 2018):
That's quite unfortunate - how big is the FreeBSD userbase? CC @LogicalPhallacy as well.
@Bond-009 commented on GitHub (Dec 12, 2018):
dotnet does "support" FreeBSD, but you need to build it from source.
Ref: https://github.com/dotnet/coreclr/blob/master/Documentation/building/freebsd-instructions.md
@Camotoy commented on GitHub (Dec 12, 2018):
I can only speak from my experience, but the FreeBSD userbase also includes FreeNAS, which currently provides an Emby package in its plugins UI.
@JustAMan commented on GitHub (Dec 12, 2018):
If one can build netcore for FreeBSD then it should be a matter of finding a maintener for FreeBSD build of Jellyfin... I am all for removing Mono support - it's already being deprecated in favor of netcore, so I think that maintaining two versions gives too much load and yields too small "profit" to the community as a whole.
P.S. Quick search says that FreeBSD has docker support since 2015, and we provide docker image.
@joshuaboniface commented on GitHub (Dec 12, 2018):
Yea I actually think Docker is the best bet for platforms that we can't/don't directly support - managing packaging for dozens of distros and OSes gets really tedious unless we have dedicated maintainers, so Docker is a nice common denominator.
FreeNAS/FreeBSD seems to support Docker: https://www.freenas.org/blog/docker-done-right/ but having not used it I can't say for sure.
@mcarlton00 commented on GitHub (Dec 13, 2018):
Last I've heard, docker on FreeBSD was still experimental.
https://wiki.freebsd.org/Docker.
Doing a bit more digging, it also appears to be unmaintained. Last commit July of 2015.
Personally, I'm in favor of compiling dotnet from source, but I have no idea how that could work on FreeNAS systems. On the bright side, it looks like dotnet might be able to get merged into ports "soon", but work seems to have stalled in recent months: https://github.com/dotnet/coreclr/issues/18067#issuecomment-418930115
Pinging @mateusrodrigues, are there any more updates or something to be done to push things along?
@mateusrodrigues commented on GitHub (Dec 13, 2018):
Hi guys. The FreeBSD version of dotnet runtime/sdk are currently still experimental. Following the steps on this tutorial were working since I built my last SDK back in August, not sure what the state is now.
I've been overwhelmed with other work, but there's a port for dotnet under review written by me here. The only problems are managed runtime components for FreeBSD need to be built on Linux and SDK components need to be copied over as-is from Linux version - which doesn't represent a problem at first because they are mostly DLLs, but I'm sure there will be some issues further along. We can only currently build native runtime components (coreclr, corefx, and core-setup). I still haven't been able to push this along, but I do plan to.
In terms of usability of runtime/sdk, I was able to run PowerShell - which is also included in the port review - using this experimental version of dotnet. However, I'm not sure how it would behave for your application.
@sparky8251 commented on GitHub (Dec 13, 2018):
Correct me if I'm wrong... Docker shares the hosts kernel with the containers it runs. I presume this is the case for FreeBSD, so even if Docker works on FreeBSD you still need FreeBSD support in Jellyfin.
@Camotoy commented on GitHub (Dec 13, 2018):
At least in the case of FreeNAS, it handles support of Docker through virtualizing a highly specific Linux distribution called Rancher, so if we're resorted to Docker it isn't a big issue. I would like to see native support of FreeBSD however but I understand that this may be issue.
@doug0162 commented on GitHub (Dec 13, 2018):
Docker on FreeNAS also requires a minimum of 2GB of RAM dedicated to the virtual machine. It'll be fine for a few early adopters, but it wont be viable for the vast majority of users given ZFS's hunger for RAM.
https://www.ixsystems.com/documentation/freenas/11.2/virtualmachines.html#docker-host-requirements
@JustAMan commented on GitHub (Dec 14, 2018):
One could always run a debian or other linux-based VM, if all else fails. At least as an intermediate solution...
@mkvalluri commented on GitHub (Dec 14, 2018):
Do we already have a branch for dotnet core migration?
@joshuaboniface commented on GitHub (Jan 9, 2019):
This should be all good now, there should be no more Mono code left.