Base image and custom transmission build

[haugene]

Hey guys 👋 I've been AFK for a while and think it's very fun that the project lives on 🙌 Big thank you to @pkishino for keeping stuff alive 🙏 Life just got too busy for a while...

I'm trying to get back on the horse again, and the first task: get dev/master branches in sync. Resolving merge conflicts and tagging a version of the image before and after the merge.

And in that work I started thinking. There are a few conflicts in the GitHub workflow setup. And... Building the haugene/transmission-builder into a separate docker image is really nice to reduce the build time of the main image.

But... I was wondering:

1. Do we need to build Transmission ourselves anymore?
2. Should we at least move the transmission-builder to a separate repository?

I'm leaning towards option 1. The main reason being maintainability. We started the custom build of Transmission because of their re-write into major version 4. We wanted to fix some issues with it being slow and having a memory leak. But we had also been on version 4 because of a distro change (if memory serves me right?) so there was something about backwards compatibility.

I think that the core feature of this image is being a plug'n'play solution that just works. And then being a bit slow on release updates will probably add to that stability - and we sacrifice the "bleeding edge" versions.

Checking our current latest image (ie the version on master branch):

docker run --rm -it haugene/transmission-openvpn:latest bash -c "transmission-daemon --version"
transmission-daemon 4.0.5 (a6fe2a64aa)

Comparing to just doing apt update && apt install transmission-daemon in a plain ubuntu container:

root@179e21d72c6f:/# transmission-daemon --version
transmission-daemon 4.0.5 (a6fe2a64aa)

It's actually the same version. Although it is true that on dev branch we have 4.0.6.
So the question is: Is it important to release an image with transmission 4.0.6 now? Or should we ditch houndreds of lines of code/config and just roll with 4.0.5 from the ubuntu repository?

If we want to have the newest Transmission. Then at least I propose that we extract all that into a separate repository that produces the base image. We already have all the code/config and github actions setup - but that would make it a cleaner separation of concerns. And it should produce a vanilla ubuntu image, just with transmission-daemon already installed. Or the .deb file readily available.

Thoughts?
I'm tagging @pkishino as the ship captain and @ksurl because it looks like you wrote most of the new github build config and extracted the transmission-builder to a separate dockerfile etc.

[pkishino]

Hmm,
https://github.com/transmission/transmission/releases/tag/4.0.6
had been out over a year.. strange it’s not in line..
It does say bug fix release..
if I get some more time I’d like to check this more (why it’s not available in eg Ubuntu sources)
I’m always in favour of keep it simple etc so happy to go with 1

[haugene]

24.04 is an LTS version. So the packages are frozen when it's released. 4.0.5 was released in December 2023 and achieved "stability" before 24.04 LTS got frozen for their release in April 2024. Then 4.0.6 was released and even if it has bug fixes it's not considered a "critical bug or security" fix version. Then it falls into the category of a "feature release" and is kept out of LTS versions.

Us keeping this image strictly on LTS versions might be a bit too conservative. Only changing base image every 2 years.
One option is to let the dev branch, or some "edge" branch use non-LTS versions and now go for 24.10 or 25.04. Both of them seem to have 4.0.6.

I'll start doing 1. then. All the code removed can just re-appear in a new repo if we want to revive the custom transmission builds.

[haugene]

I got a few hours to have a look today and ended up with a (for now) three step process:

1. I'm reverting feat(upgrade): ubuntu 24.04 LTS for base (was 22.04) #2907 (temporarily, as 24.04 comes back in step 3). The reason I revert it is that it also brought back the Transmission build in the main Dockerfile and that gave more merge conflicts between master and dev.
2. I merged the master branch into dev. Good pre-requisite before making more changes, and possibly producing more conflicts.
3. I removed our custom Transmission build, re-upgraded the base image to 24.04, and installed transmission using APT.

Step 1+2 is gathered is here: #2940
Step 3 is here: #2941

Separating it was just done to make it clearer what's what. They should be merged in one go. So before merging I'll just change the merge target of #2941 to dev and merging will then close them both.

I've built and run the container successfully on my machine. Everything looks OK from the logs at least and I can open Transmission.
I'll do some more testing before merging 👍

[ksurl]

I have no problems with going back to in repo install rather than custom build if it's preferred to use newer base os to skip custom builds.