Jellyfin: Please create a non-docker build path

Created on 22 Jan 2020  路  3Comments  路  Source: jellyfin/jellyfin

Describe the bug

293 shows a request for Synology NAS build. The problem is that your current build process is all done within a docker container. Our builds are within a docker container. The permission for a container to itself launch a container can be tricky.

If there was a ./build script that noted dependencies, and checked for what it needs, then build if all dependencies were found, that would help. Not installing missing dependencies, just confirm that the necessary binaries or libs are present. Not packages or RPMs or DEBs or APKs or PKGs or other inconsistently-named wrappers, but binaries or libraries checked by trying to use them. A traditional auto tools (./configure, make install) would be the easiest because those variables are consistent to override, but that's too old and difficult for some, I get that. Not patronizing, just recognizing that build processes have diverged with CI/CD pipelines.

Looking at the binary packages you offer for your releases, there are many options, but we'd be looking at various architectures and possibly different releases of libraries, so the mapping of you <--> us would be difficult to build and possibly fragile from DSM release to DSM release.

To Reproduce

  1. review the linux build options in ./build --list-platforms
  2. find the one that builds without running a custom docker image

Expected behavior
A build path that checks for dependencies by checking behavior (not names) and -- finding everything -- builds binaries to $(DESTDIR)

Logs

Screenshots

System (please complete the following information):

  • OS: Synology DSM (arch, i386, x86, etc) (debian:buster -based cross-build system)
  • Browser: vi, gnumake :)
  • Jellyfin Version: 10.4.3
  • Installed Plugins: none
  • Reverse proxy: none (nothing but 'net, baby)

Additional context
I'm sorry if I'm describing things incorrectly; I don't know azure pipelines, and don't know dot-net, but I do know packaging on many forms of linux and unix, especially, Synology this week.

bug

Most helpful comment

The build script is primarily used for our automatic building. It's not necessarily intended to be as part of a 3rd party's build process. Since you are building with docker, reference our Dockerfile that contains the actual build steps for the docker container we publish (aka, it includes dependencies and steps to build and package the server).

https://github.com/jellyfin/jellyfin/blob/master/Dockerfile

All 3 comments

The dockerization is intended to ensure reproduceability of the builds. You can use dotnet publish directly with the required arguments (check the deployment/debian-package-x64/pkg-src/rules file for a command) to build the binary directly.

The build script is primarily used for our automatic building. It's not necessarily intended to be as part of a 3rd party's build process. Since you are building with docker, reference our Dockerfile that contains the actual build steps for the docker container we publish (aka, it includes dependencies and steps to build and package the server).

https://github.com/jellyfin/jellyfin/blob/master/Dockerfile

Looks like this was asked in #528.

This affects porting to Synology, which apparently in demand, but requires effort on both sides. As discussed in SynoCommunity/spksrc#3660 the lift to package a unique build system unlike other tools unaided and with many new dependencies plus a risk around dotnet dependency specifically is unlikely in the short term

Was this page helpful?
0 / 5 - 0 ratings

Related issues

triDcontrols picture triDcontrols  路  3Comments

MSG-maniac picture MSG-maniac  路  3Comments

mcarlton00 picture mcarlton00  路  3Comments

grravity picture grravity  路  3Comments

YouKnowBlom picture YouKnowBlom  路  3Comments