Make exim more configurable

Dear Luca Ceresoli,

Quoted 21 lines · Luca Ceresoli

Quoted 6 lines

However, I've for now rejected those two patches. The reason is that I don't think we should add an option to customize the user with which each and every daemon is started. Buildroot should use a sane default option, and for additional configuration, leave it to the Buildroot user to use BR2_ROOTFS_USERS_TABLES to create any additional/custom user that may be needed.

I generally agree with you.

The problem with exim is that it does not allow to configure its user from a runtime configuration file, because it's hard-coded in the binary. The only way to select a user is to change the build-time configuration.

So, it's true that one can easily create a new user for exim using BR2_ROOTFS_USERS_TABLES. But currently the only way to tell exim to use that user is to supply an entire config file (which is possible thanks to patch 1 that you've just applied). This would bring out of sync from changes in the config file coming from upstream (exim as well as Buildroot).

Quoted 3 lines

Patch 2 allows one to keep the Buildroot-provided configuration file, and Buildroot would take care of tweaking the one line needed to actually use the new username.

Well, I think we generally support two cases in Buildroot:

1) A basic, default, sane configuration. This is what already existed prior to your patch series, where exim uses a dedicated user created by the exim package.

2) A way of providing a custom configuration, which is possible thanks to the BR2_ROOTFS_USERS_TABLES plus the possibility of providing a custom Exim configuration file.

Of course, it means than if all you want is to change the user with which Exim is running, you have to go with option (2), even if for all other options you need to keep the exact same options as the ones normally used with option (1).

But it's exactly the same as with the kernel: if you can use a defconfig, it's easy and simple. If you need to use a defconfig + one more option, then you have no other choice than switching to using your own kernel configuration file. We won't add Config.in options for each and every kernel options.

And therefore I don't think we should add Config.in options for each and every exim configuration option. You might be interested by changing the user, but the next user will be interested in changing this other knob, and so on and so on. We clearly don't want to go down that road, and instead we want to go for option (2) by providing a general customization solution, which allows to solve the problem, even if it requires a little bit of effort if your customization is only related to one or two differences compared to the basic Buildroot configuration.