From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Ceresoli Date: Wed, 16 Jul 2014 11:03:29 +0200 Subject: [Buildroot] [PATCH 0/3] Make exim more configurable In-Reply-To: <20140716102957.76a63a7a@free-electrons.com> References: <1404489386-7523-1-git-send-email-luca@lucaceresoli.net> <20140715213125.1b848b48@free-electrons.com> <53C63546.4040204@lucaceresoli.net> <20140716102957.76a63a7a@free-electrons.com> Message-ID: <53C63FE1.1010308@lucaceresoli.net> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Dear Thomas, Thomas Petazzoni wrote: > 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 >> 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). >> >> 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. Well, yes, that's true... I'm probably biased by the fact that configuring exim is so uncomfortable, but that's no excuse I guess. :) -- Luca