Portable builds for musl-based Linux systems

[FintasticMan]

I would like to propose adding a build option to the CI for musl-based Linux distributions, such as Alpine Linux. From my rudimentary testing, jellyfin-ffmpeg should work just fine, with the exception of CUDA not being possible. I'm also not sure whether AMF is possible tbh, but I can look into that.

I've already made an Alpine Linux package, mostly using the configure options from the Arch package. That can be found here.

If this isn't something you'd be interested in, feel free to close.

[gnattu]

Using musl can introduce compatibility issues with certain libraries we depends on, including those you mentioned. Additionally, OpenSSL is known to have issues when using musl on arm64 architectures(not sure if fixed now). Even the Jellyfin server itself doesn't work well with musl, as dotnet doesn't officially support it and requires some hacks. Since we don't officially support musl targets, I'm hesitant to provide official musl builds. We cannot guarantee the functionality for such builds either.

Feel free to fork this repo and modify the CI for musl if you want to build it for alpine, but you will be responsible for any unexpected behaviors for those builds.

[FintasticMan]

I see. Thanks for the explanation!

[Bond-009]

We already provide musl (both x86_64 and aarch64) builds for unstable https://repo.jellyfin.org/?path=/server/linux/latest-unstable/amd64-musl And I assume we will also have stable builds once 10.9 releases

[gnattu]

We already provide musl (both x86_64 and aarch64) builds for unstable https://repo.jellyfin.org/?path=/server/linux/latest-unstable/amd64-musl And I assume we will also have stable builds once 10.9 releases

But it is still hard to support for jellyfin-ffmpeg as we cannot ensure hardware acceleration would work properly.

[FintasticMan]

Well, it should be obvious to anyone using musl that CUDA should never work, as there are no NVIDIA drivers for musl. AMF might work, haven't checked, and VAAPI and QSV should work fine. I would say that providing builds, even if untested, would be better than directing people to upstream FFmpeg.

[gnattu]

I would say that providing builds, even if untested, would be better than directing people to upstream FFmpeg.

However, it does not work that way. We have to deal with all the consequences of being untested, and if we mark it as an officially supported target, we will be responsible for fixing all the runtime and build time problems.

If you really, really want this happen, you can set up your own CI to create such builds, and we will document it on our website, marking it as community-supported, just like how we are doing with RPM builds in 10.9. We dropped all our official RPM repos in favor of RPMFusion's builds.