Open discussion about the future of the image

[romancin]

Hi everyone!

I am making tests to give this image support on Alpine 3.12, as it was released a few months ago.

This time, as this image is used by thousands of users, I think that is better to open a new discussion so everyone gives their opinion about the current situation I would like to solve.

Rtorrent 0.9.8 is supported by the vast majority of trackers, so I am start thinking that maintaining older versions is not needed anymore. If you take a look at Jenkinsfile and Dockerfile, older versions of rtorrent doesn't run on latest Alpine versions, so I need to make a lot of "awful" patches using conditionals depending on the version of rtorrent in order to build the image accordingly. This things complicates a lot with each Alpine version that is released. In Alpine 3.12, things get worse. As stated on its Release notes, this version changes python support. Python v2 went out of support on January 2020, so the community behind Alpine has taken the decision to start the process to remove it. In Alpine 3.12, pip is not included anymore on python package, so I need to change python installation in the Dockerfile for different image versions, so it would add more complexity and more "patches" are needed so I can continue building images for every rtorrent version. I think this wouldn't make sense anymore.

In my opinion, since this moment I think the best option is to take out of support every rtorrent version older than 0.9.8. This version would run perfectly on Alpine 3.12, so this way I can center only on this version and it would be much easier for me to improve it much more frequently, as testing only one version would be really easy.

Another important thing if I take this decision is what to make with pyrocore. Right now, pyrocore only supports Python 2. There is an issue open on pyrocore repository since more than 4 years ago, and right now it continues to be supported only on Python 2. I am convinced that it's time to say goodbye to Python 2. When I update the image to Alpine 3.12, pyrocore will need to be removed. This is something I don't use, so there will be no problem for me, but I would like to know how many people use it to evaluate if this would be a problem.

Please, your opinion is needed to see what is the best way to proceed with these.

Another thing I am thinking, but only in case of supporting only the latest rtorrent version, is unifying rutorrent-flood-docker and rutorrent-docker repositories. Using an environment variable, we can select to start flood or not. The only concern about this is that flood image is bigger than the one without it, so I don't know if you think this could be a good idea.

Thank you anyone.

[Koldnitz]

Romancin,

None of these changes would affect me personally, and even if they did I would deal with it.

I am just glad you still maintain these images which I have been using for 3+ years now.

I think unifying rutorrent/ rutorrent-flood would be a good idea because it would make it easier for you to maintain both images.

Thanks for your (and everyone's) hard work.

[romancin]

Romancin,

None of these changes would affect me personally, and even if they did I would deal with it.

I am just glad you still maintain these images which I have been using for 3+ years now.

I think unifying rutorrent/ rutorrent-flood would be a good idea because it would make it easier for you to maintain both images.

Thanks for your (and everyone's) hard work.

Thank you very much for your opinion. It is a pleasure for me to collaborate with the opensource community, as I enjoy projects developed by other people, it’s a honor for me that so much users enjoy mine too 😉

[imjuzcy]

hey romancin, I do use pyrocore, namely for the custom python code to check for free space before starting downloads. However, I do understand if you would like to drop pyrocore in future versions of the image if it's too much work for you to maintain it. Honestly it's absurd that after 4 years of that issue on that repo they still haven't change to Python 3.

[rapejim]

In my point of view, if version 0.9.8 is compatible with most trackers, I don't see the need to maintain previous versions (in any case, leave them in a deprecated/obsolete state).

And in relation to rutorrent-flood-docker... would it be easier if the construction of the rutorrent-flood-docker image would use your own rutorrent-docker image as the "base image" and then install flood? (or am I saying something crazy? 😅)

[imjuzcy]

@romancin Anyway, is there any reason you're using Alpine as base other than because it's small in size? The plugin filemanager needs rar, which is not available for Alpine. I don't use filemanager to compress, so I doesn't affect me, but it just pops out an error every time I go the the ruTorrent web interface.

[romancin]

In my point of view, if version 0.9.8 is compatible with most trackers, I don't see the need to maintain previous versions (in any case, leave them in a deprecated/obsolete state).

And in relation to rutorrent-flood-docker... would it be easier if the construction of the rutorrent-flood-docker image would use your own rutorrent-docker image as the "base image" and then install flood? (or am I saying something crazy? 😅)

Good catch, now that older rtorrent versions are deprecated, it is much easier to maintain flood image using this repository as the base. In fact, I have just done it :)

[romancin]

@romancin Anyway, is there any reason you're using Alpine as base other than because it's small in size? The plugin filemanager needs rar, which is not available for Alpine. I don't use filemanager to compress, so I doesn't affect me, but it just pops out an error every time I go the the ruTorrent web interface.

I use Alpine because of its size, there is no other reason. I know the problem with rar, but changing this image to use another distro is too much effort for only that functionality.