Make exim more configurable
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 3 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 0/3] 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_TABLESto 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.
Of course, others are very welcome to enter this discussion and give their opinion.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com