Transfer scattered docker attempts to an unified multi-arch building docker image inside the amule project

[viperey]

Hi there.
I'd like to propose to include inside this repository the files and docs needed to make the amule project "officially" support docker.

The dockerization itself is not mine, it's based on the (amazing) work previously made by other devs (check the README).

I'm basically gathering such knowledge, giving it some packaging around a single image/tag with multi-architecture support.

It would be nice also to hear about @tchabaud & @synopsis8 opinions in this regard.

The PR has big areas of improve, but I'd say, this is a valid starting point for this proposal and It will be positive to hear the feedback from the rest of the community before proceeding with any further work and steps.

Best.

[synopsis8]

For me, it completely makes sense. I'd fully support that, I just had no time after some unsuccessful attempts.
It this would also automate the docker builds, that would be awesome

[t-chab]

I totally agree too, it would be a nice improvment if Dockerfile could be merged upstream.

[ngosang]

If you use debian as base image you can build for more architectures. I'm not building from source but it's possible since someone is building official packages.

• https://hub.docker.com/r/ngosang/amule/tags
• https://github.com/ngosang/docker-amule#supported-architectures

[minnyres]

It is actually not necessary to write a dockerfile for each CPU architecture. I can build a multi-arch aMule docker image by

docker buildx build -f official-2.3.3/Dockerfile  --platform linux/arm,linux/arm64,linux/amd64  -t minnyres/amule-dlp:official-2.3.3 . --push

[Vollstrecker]

As versions are scattered all over these files, who want's to maintain this stuff? The same guy that wrote upnp-1.6.22 a version that's over 5 years old? And cryptopp-5.6.5 from 6 years ago? If anything goes wrong we get bugreports where we ask for more current versions and the users tell us that they can't influence that?

And why should we distribute a dockerfile that explicitely loads other thems because ours is ugly?

[minnyres]

As versions are scattered all over these files, who want's to maintain this stuff? The same guy that wrote upnp-1.6.22 a version that's over 5 years old? And cryptopp-5.6.5 from 6 years ago? If anything goes wrong we get bugreports where we ask for more current versions and the users tell us that they can't influence that?

And why should we distribute a dockerfile that explicitely loads other thems because ours is ugly?

I agree. There is no need to build from source. To make thing easier, we can maintain a Debian based docker image that install aMule via

apt install amule-daemon

or

apt install amule

I also wonder if it is possible to build a static release for Linux like that: https://github.com/userdocs/qbittorrent-nox-static

[Vollstrecker]

If you want to install via apt, there is a repo (it's the original debian repo), I don't see any point in adding docker around the binary. If the binary doesn't work in the distros that are shipping it, this needs to be fixed, not worked around. You noticed the problems with log4j, Java like to bundle stuff and noone could easily tell where the broken lib was in. Docker has the potential to do the same.

For the static build, with autotools there is an option to do that, with cmake I'm working on dependant libs to make it possbile.

[ngosang]

@minnyres I already did most things you mentioned.

• Base Debian Docker image https://github.com/ngosang/docker-amule/blob/master/Dockerfile
• Install the compiled binaries from Debian repository
• Support of 7 architectures with 1 Dockerfile. Auto build and publish with GitHub actions. https://github.com/ngosang/docker-amule#supported-architectures

Although I'm not doing it, I think it is a good idea to build aMule and all required libs from source code in the Dockerfile. In that way we don't have to wait for new Debian packages. We can build Docker images automatically in every PR or commit. We can also control the exact versions of the libraries and compile them with specific parameters if required. Docker allows multi-stage builds, so you can install the build dependencies an compile in one stage and include only the final executables in the final image. That is what we are doing in Gerbera (another C++ project) => https://github.com/gerbera/gerbera/blob/master/Dockerfile

Anyway, the main concern with this project is the inactivity. There are several important issues related to memory leaks, bad traces and crashes... no one is taking care of them so this is low priority for me.

I will maintain my repository and Docker images updated. You can copy all you need from my repository too. https://github.com/ngosang/docker-amule

[minnyres]

@ngosang great work! Hope these issues can be solved one day.