[Buildroot] [PATCH 0/3] Make exim more configurable
thomas.petazzoni at free-electrons.com
Wed Jul 16 08:29:57 UTC 2014
Dear Luca Ceresoli,
On Wed, 16 Jul 2014 10:18:14 +0200, Luca Ceresoli wrote:
> > 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
> 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
> 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
Of course, others are very welcome to enter this discussion and give
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
More information about the buildroot