Skip to content

RFC Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)

Thomas Petazzoni buildroot 1 version New

Get series with b4
b4 am [email protected]

Versions newest first

  1. v1 RFC Latest0 of 7 patches 0 repliesNew

Patches in v1 No applies recorded yet

None of the 7 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.

Read the v1 thread

Cover letter [Buildroot] [PATCH 0/7] [RFC] Introduce services as a (long-term) replacement for _INSTALL_INIT_(SYSV|SYSTEMD) (branch yem/services)

Dear Yann E. MORIN,

Quoted 3 lines · Yann E. MORIN

Following up on Gustavo's proposal [0] on a clean up on our init scripts (and eventually our systemd unit files), here is an *RFC* series that tries to implement Gustavo's idea.

I am personally not in favor of an approach where kconfig options are used to enable/disable services, because it's a slippery slope. I very much prefer Gustavo's proposal of /etc/{default,config}/ files, that users can override in their rootfs overlays or post-build script.

Why do I have this opinion?

Simply because your proposal is limited to just enabling/disabling services. But then people will want kconfig options to set the TFTP server root directory, to set the lighttpd server options foo or bar, to configure the NTP configuration options, and so on. This is clearly not a direction we want to take I believe as it will simply require more and more and more kconfig options.

Instead, let's have some /etc/default/<service> files, which allow to both define whether <service> is enabled or not, but also allow to set various other service-specific configuration options.

I think Buildroot is a toolbox to generate your system, but you *must* do some additional customization to have a system tailored to your needs. What I believe is great in Buildroot is that is basically just builds the upstream source code, and installs it. It doesn't try to be a distro that imposes its own Web interface, its own organization of the filesystems, etc. We just build and install everything, and provide minimal sane defaults, and let users customize everything else.

Best regards,

Thomas

Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Read the cover letter in its thread