Context

DMS currently supports amd64 and aarch64. It does not support riscv64. It would be nice if this was added. Furthermore, it would be nice if DMS was more architecture agnostic in its build approach in general.

Description

Implement support for building and running the Docker image on RISC-V.

Alternatives

Not running DMS on riscv64 but on amd64 and aarch64 instead. Which is fine as well, of course. 😄

Applicable Users

Users running DMS on RISC-V processors. This will be a low number currently. If RISC-V takes off and becomes more popular (on SBC's, in the VPS space, etc.), it is a given that requests for better support of selfhosted services such as email will increase.

Are you going to implement it?

Yes, because I know the probability of someone else doing it is low and I can learn from it.

What are you going to contribute?

First of all, this is merely an exploration of the concept and maybe an implementation, depending on the results of the exploration.

How I see the future chronologically:

1. Explore if support for other architectures in general and RISC-V in particular is desired by DMS developers, contributors and the community. This determines whether we will continue with the next steps.
2. Make DMS more portable without sacrificing what makes it so great. This development could start and be included in DMS at any moment.
3. Add RISC-V support. The inclusion of this in DMS should wait until it is based on Debian 13 (trixie), since Debian 13 supports RISC-V. And this of course has to wait until Debian 13 is stable. 😉

More about 2:
Currently a number of community repositories is used for binary packages, and at least one "hack" is used for build optimization. This brings some advantages: lower build time, less system resources being used, newer software releases, etc. However, most of these binary package repositories are limited in the architectures they support. What I want is to have a "default" build path for DMS that works on any architecture supported by the currently used Debian version. On top of that, architecture-specific optimizations should be supported and used by default, but not be necessary for a successful build. In other words: nothing needs to change for the currently supported architectures if this would be implemented. It just opens the door to more easily support new architectures.

I privately forked DMS and made a test version of DMS that builds (not necessarily runs!) on RISC-V. Changes I had to make:

• Add riscv64 as a supported architecture (ARCH_A=riscv64 and ARCH_B=riscv64).
• In Dockerfile change the base from docker.io/debian:12-slim to docker.io/debian:testing-slim. Due to this I also had to make the following changes (not related to RISC-V specifically):
  • Replace adduser with useradd.
  • Remove liblz4-tool from packages.sh.
• Due to a lack of RISC-V binaries in several third party repositories:
  • Disable the Rspamd third-party repository (no RISC-V binaries) so Rspamd is installed from Debian instead.
  • Replace jaq. I opted for using jq (included with Debian).
  • Use freshclam during package build to initiate ClamAV definitions. This is due to the "hack" with ripping these files from ClamAV's Debian docker image does not work if the latter does not support the architecture under which Docker is running.
  • Build step myself.

Based on this prototype I have a fairly good idea about what needs to be done for step 2. I'll ignore the Debian 13 changes, since that is a more generic issue that I am sure that will be (or maybe already is) solved by DMS itself. The changes I see to make DMS more portable:

• Make the use of the Rspamd third-party repository optional. packages.sh states that the included Rspamd in the current Debian stable is too old (according to Rspamd's developers). Two options for an unsupported architecture: use the older version, or compile the latest stable Rspamd version. I would prefer the latter. Both options could be supported, but my preference would be to compile a newer version by default. So in order of preference:
  • Use Rspamd repository for binary package (if architecture is supported)
  • Build latest stable Rspamd ourselves (if architecture is not supported)
  • Fall back on Rspamd included in Debian (if the user decides to do so)
• Replace jaq with jq. As far as I see, jaq is only used by update-check.sh. I think it is better to use something directly supported by Debian if it means using one less third-party repository.
• Use freshclam by default to update ClamAV definitions, except if an architecture supported by ClamAV's Debian docker image is used. In that case, use the current approach.
• Build step, except if an architecture is used for which binary packages are available.

I am interested in making DMS more portable and to add RISC-V support. Now some questions for you (DMS developers, contributors, community):

1. I have shown my interest, but are others interested? If you only want to answer this question without elaborating, consider a thumb up or a thumb down on this opener instead of a reply.
2. What do you think of my proposal of making DMS more portable? Do I do something in a stupid way or forget something? 😉 Does something I propose deviate from the DMS development philosophy? How could it be improved?
3. I have no experience with the QA part of Docker Mailserver, such as the checks that are performed in a PR is submitted. Is it easy to add support for new architectures (such as RISC-V) to the current test procedures?