@nvllsvm and I both discussed and agreed that we should separate this out, as having it with the server backend doesn’t make much sense as the packaging framework grows and changes. For simplicity of discussion, let’s call the new repo
That said, I think it’s best to decide first how to handle combining the 3 repositories (or more, if we also add support for doing the various client apps within the same build framework) to build them, before doing the actual split. From my perspective there’s two main ways to proceed here:
jellyfin-packaginginto the main repo:
This would be “simple”, but also could have unintended side effects.
- Direct script-based cloning, where the main
buildscript pulls the required repositories into a known location and goes the submodule initialization.
This might be more flexible, but would make the
jellyfin-packaging repository the “main” one needed to build the others.
We also need to determine where to put things like e.g. the Dockerfiles - I understand @nvllsvm’s desire to keep them in the root of the main repo, however if we’re splitting out packaging that would imply that Docker packaging would be moved too. And this adds the complexity of new users determining exactly where they go to “run it”.