common service startup files
v2 cover common service startup files
This series is intended to simplify and clean up installation routine for daemon-like applications, merging sysv and systemd startup files and moving much of the common code out of per-package .mk files.
Currently buildroot requires pre-crafted sysv and/or systemd startup files to be supplied for each package that needs its daemon-like processes started at system boot. In many cases, this is redundant.
Only a small part of the startup scripts is package-specific. A single command, the one that starts the process in foreground mode, is typically enough to generate usable sysv and systemd startup files.
Separating package-specific data and removing the rest from package directories allows changing common code without the need to patch several dozen packages, ensures more or less even support for sysv and systemd, and potentially simplifies introduction of alternative system startup schemes.
The first patch in the series contains the common code, and the rest show how it affects individual packages. I'm only posting a few interesting ones with comments; the full set (~50 patches) is available
here: https://github.com/arsv/br/ branch run-1.
---
v2 changes: this part of the v1 series is now standalone, the script got simplified a lot, and it now requires explicit variables instead of just picking up files from the package directory.
Run files format reverted to "key: value" with explicit keys. It is still somewhat custom, and the script is still in python however.
Non-daemon script support dropped completely, and some rare complex cases like postgres dropped as well.
Hard-coded paths removed, TARGET_DIR is used when appropriate.
Variable substitution and special cases are now handled in package makefiles, not in the script.
Signature · 1 line
2.0.3
RFC v2 1/6 common service startup files
This patch introduces support infrastructure for per-project .run files containing the information needed to generate either sysv intiscripts or systemd services in a common format.
Packages are expected to set $(PKG)_INIT_RUN = list of .run files to install in their .mk files, allowing pkg-generic to call support/init/install with appropriate arguments.
Alternatively, packages may define $(PKG)_INSTALL_INIT, calling support/init/install themselves or doing something more elaborate. Packages may also define $(PKG)_INSTALL_INIT_SYSV or _SYSTEMD, overriding non-specific _INSTALL_INIT.
The format of the .run files is simple set of "key: value" lines, reflecting the structure of the data while also being somewhat readable.
Explicit $(PKG)_INIT_RUN in every .mk file provides clues for unaware users regarding the purpose of otherwise unremarkable .run files. INIT_RUN string is grepable.
--- package/pkg-generic.mk | 26 +++- package/pkg-utils.mk | 4 + support/init/install | 349 +++++++++++++++++++++++++++++++++++++++++++++++++ system/Config.in | 6 + 4 files changed, 381 insertions(+), 4 deletions(-) create mode 100755 support/init/install
package/pkg-generic.mk +22 -4
@@ -235,10 +235,7 @@ $(BUILD_DIR)/%/.stamp_target_installed: @$(call MESSAGE,"Installing to target") $(foreach hook,$($(PKG)_PRE_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep)) +$($(PKG)_INSTALL_TARGET_CMDS) - $(if $(BR2_INIT_SYSTEMD),\ - $($(PKG)_INSTALL_INIT_SYSTEMD)) - $(if $(BR2_INIT_SYSV)$(BR2_INIT_BUSYBOX),\ - $($(PKG)_INSTALL_INIT_SYSV)) + +$($(PKG)_INSTALL_INIT_$(INIT)) $(foreach hook,$($(PKG)_POST_INSTALL_TARGET_HOOKS),$(call $(hook))$(sep)) $(Q)if test -n "$($(PKG)_CONFIG_SCRIPTS)" ; then \ $(RM) -f $(addprefix $(TARGET_DIR)/usr/bin/,$($(PKG)_CONFIG_SCRIPTS)) ; \
@@ -763,6 +760,27 @@ ifneq ($$(call suitable-extractor,$$($(2)_SOURCE)),$$(XZCAT)) DL_TOOLS_DEPENDENCIES += $$(firstword $$(call suitable-extractor,$$($(2)_SOURCE))) endif +ifeq ($(4),target) + +ifndef $(3)_INSTALL_INIT + ifdef $(3)_INIT_RUN + define $(3)_INSTALL_INIT + support/init/install $(BR2_INIT) $(TARGET_DIR) \ + $$(addprefix $(pkgdir),$$($(3)_INIT_RUN)) + endef + endif +endif + +# Init-specific rules override generic INSTALL_INIT +ifndef $(3)_INSTALL_INIT_$(INIT) + ifdef $(3)_INSTALL_INIT + $(3)_INSTALL_INIT_$(INIT) = $$($(3)_INSTALL_INIT) + endif +endif + +endif # $(4) == target + + endif # $(2)_KCONFIG_VAR endef # inner-generic-package
package/pkg-utils.mk +4 -0
@@ -76,6 +76,10 @@ INFLATE.tar = cat # suitable-extractor(filename): returns extractor based on suffix suitable-extractor = $(INFLATE$(suffix $(1))) +# Uppercase init name suitable for use in variables +# BR2_INIT="sysv" INIT=SYSV +INIT = $(call UPPERCASE,$(call qstrip,$(BR2_INIT))) + # MESSAGE Macro -- display a message in bold type MESSAGE = echo "$(TERM_BOLD)>>> $($(PKG)_NAME) $($(PKG)_VERSION) $(call qstrip,$(1))$(TERM_RESET)" TERM_BOLD := $(shell tput smso)
support/init/install new file +349 -0
349 lines not on this page · raw message
system/Config.in +6 -0
@@ -107,6 +107,12 @@ config BR2_INIT_NONE endchoice +config BR2_INIT + string + default "sysv" if BR2_INIT_SYSV || BR2_INIT_BUSYBOX + default "systemd" if BR2_INIT_SYSTEMD + default "none" + choice prompt "/dev management" if !BR2_INIT_SYSTEMD default BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_DEVTMPFS
Signature · 1 line
2.0.3
RFC v2 2/6 squid: common service startup
In reply to Alex SuykovA typical simple daemon.
--- package/squid/S97squid | 40 ---------------------------------------- package/squid/squid.mk | 5 +---- package/squid/squid.run | 3 +++ 3 files changed, 4 insertions(+), 44 deletions(-) delete mode 100755 package/squid/S97squid create mode 100644 package/squid/squid.run
package/squid/S97squid deleted +0 -40
@@ -1,40 +0,0 @@ -#!/bin/sh - -[ -x /usr/sbin/squid ] || exit 0 -[ -f /etc/squid.conf ] || exit 0 - -case "$1" in - start) - echo -n "Starting squid: " - if [ ! -d /var/log/squid ]; then - mkdir -p /var/log/squid - chown squid:squid /var/log/squid - fi - start-stop-daemon -S -x /usr/sbin/squid - [ $? = 0 ] && echo "OK" || echo "FAIL" - ;; - - stop) - echo -n "Stopping squid: " - /usr/sbin/squid -k shutdown - [ $? = 0 ] && echo "OK" || echo "FAIL" - ;; - - reload) - echo -n "Reloading squid configuration: " - /usr/sbin/squid -k reconfigure - [ $? = 0 ] && echo "OK" || echo "FAIL" - ;; - - restart) - echo -n "Restarting squid: " - /usr/sbin/squid -k restart - [ $? = 0 ] && echo "OK" || echo "FAIL" - ;; - - *) - echo "Usage: $0 {start|stop|reload|restart}" - exit 1 -esac - -exit 0
package/squid/squid.mk +1 -4
@@ -76,9 +76,6 @@ define SQUID_USERS squid -1 squid -1 * - - - Squid proxy cache endef -define SQUID_INSTALL_INIT_SYSV - $(INSTALL) -m 755 -D package/squid/S97squid \ - $(TARGET_DIR)/etc/init.d/S97squid -endef +SQUID_INIT_RUN = squid.run $(eval $(autotools-package))
package/squid/squid.run new file +3 -0
@@ -0,0 +1,3 @@ +description: Squid proxy server +prestart: mkdir -p /var/log/squid +foreground: /usr/sbin/squid -N
Signature · 1 line
2.0.3
RFC v2 3/6 dropbear: common service startup
In reply to Alex SuykovRelatively complex case, with umask and autid dependency.
--- package/dropbear/S50dropbear | 43 --------------------------------------- package/dropbear/dropbear.mk | 13 +----------- package/dropbear/dropbear.run | 6 ++++++ package/dropbear/dropbear.service | 10 --------- 4 files changed, 7 insertions(+), 65 deletions(-) delete mode 100644 package/dropbear/S50dropbear create mode 100644 package/dropbear/dropbear.run delete mode 100644 package/dropbear/dropbear.service
package/dropbear/S50dropbear deleted +0 -43
@@ -1,43 +0,0 @@ -#!/bin/sh -# -# Starts dropbear sshd. -# - -# Allow a few customizations from a config file -test -r /etc/default/dropbear && . /etc/default/dropbear - -start() { - DROPBEAR_ARGS="$DROPBEAR_ARGS -R" - - echo -n "Starting dropbear sshd: " - umask 077 - start-stop-daemon -S -q -p /var/run/dropbear.pid \ - --exec /usr/sbin/dropbear -- $DROPBEAR_ARGS - [ $? = 0 ] && echo "OK" || echo "FAIL" -} -stop() { - echo -n "Stopping dropbear sshd: " - start-stop-daemon -K -q -p /var/run/dropbear.pid - [ $? = 0 ] && echo "OK" || echo "FAIL" -} -restart() { - stop - start -} - -case "$1" in - start) - start - ;; - stop) - stop - ;; - restart|reload) - restart - ;; - *) - echo "Usage: $0 {start|stop|restart}" - exit 1 -esac - -exit $?
package/dropbear/dropbear.mk +1 -12
@@ -51,19 +51,8 @@ define DROPBEAR_DISABLE_STANDALONE $(SED) 's:\(#define NON_INETD_MODE\):/*\1 */:' $(@D)/options.h endef -define DROPBEAR_INSTALL_INIT_SYSTEMD - $(INSTALL) -D -m 644 package/dropbear/dropbear.service \ - $(TARGET_DIR)/usr/lib/systemd/system/dropbear.service - mkdir -p $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants - ln -fs ../../../../usr/lib/systemd/system/dropbear.service \ - $(TARGET_DIR)/etc/systemd/system/multi-user.target.wants/dropbear.service -endef - ifeq ($(BR2_USE_MMU),y) -define DROPBEAR_INSTALL_INIT_SYSV - $(INSTALL) -D -m 755 package/dropbear/S50dropbear \ - $(TARGET_DIR)/etc/init.d/S50dropbear -endef +DROPBEAR_INIT_RUN = dropbear.run else DROPBEAR_POST_EXTRACT_HOOKS += DROPBEAR_DISABLE_STANDALONE endif
package/dropbear/dropbear.run new file +6 -0
@@ -0,0 +1,6 @@ +description: Dropbear SSH daemon +umask: 077 +pidfile: /var/run/dropbear.pid +after: syslog network auditd +background: /usr/sbin/dropbear -R +foreground: /usr/sbin/dropbear -F -R
package/dropbear/dropbear.service deleted +0 -10
@@ -1,10 +0,0 @@ -[Unit] -Description=Dropbear SSH daemon -After=syslog.target network.target auditd.service - -[Service] -ExecStart=/usr/sbin/dropbear -F -R -ExecReload=/bin/kill -HUP $MAINPID - -[Install] -WantedBy=multi-user.target
Signature · 1 line
2.0.3
RFC v2 4/6 samba4: common service startup
In reply to Alex SuykovTwo daemons per package, each gets it own .run file.
This will result in two .service files (which is the only way with systemd) and two initscripts.
--- package/samba4/S91smb | 56 ------------------------------------------------ package/samba4/nmbd.run | 3 +++ package/samba4/samba4.mk | 6 +----- package/samba4/smbd.run | 3 +++ 4 files changed, 7 insertions(+), 61 deletions(-) delete mode 100644 package/samba4/S91smb create mode 100644 package/samba4/nmbd.run create mode 100644 package/samba4/smbd.run
package/samba4/S91smb deleted +0 -56
@@ -1,56 +0,0 @@ -#!/bin/sh - -[ -f /etc/samba/smb.conf ] || exit 0 - -mkdir -p /var/log/samba - -start() { - echo -n "Starting SMB services: " - smbd -D - [ $? = 0 ] && echo "OK" || echo "FAIL" - - echo -n "Starting NMB services: " - nmbd -D - [ $? = 0 ] && echo "OK" || echo "FAIL" -} - -stop() { - echo -n "Shutting down SMB services: " - kill -9 `pidof smbd` - [ $? = 0 ] && echo "OK" || echo "FAIL" - - echo -n "Shutting down NMB services: " - kill -9 `pidof nmbd` - [ $? = 0 ] && echo "OK" || echo "FAIL" -} - -restart() { - stop - start -} - -reload() { - echo -n "Reloading smb.conf file: " - kill -HUP `pidof smbd` - [ $? = 0 ] && echo "OK" || echo "FAIL" -} - -case "$1" in - start) - start - ;; - stop) - stop - ;; - restart) - restart - ;; - reload) - reload - ;; - *) - echo "Usage: $0 {start|stop|restart|reload}" - exit 1 -esac - -exit $?
package/samba4/nmbd.run new file +3 -0
@@ -0,0 +1,3 @@ +description: Samba NMB daemon +prestart: mkdir -p /var/log/samba +foreground: /usr/sbin/nmbd -F
package/samba4/samba4.mk +1 -5
@@ -13,6 +13,7 @@ SAMBA4_LICENSE_FILES = COPYING SAMBA4_DEPENDENCIES = host-e2fsprogs host-heimdal e2fsprogs popt python zlib \ $(if $(BR2_PACKAGE_LIBCAP),libcap) \ $(if $(BR2_PACKAGE_READLINE),readline) +SAMBA4_INIT_RUN = smbd.run nmbd.run ifeq ($(BR2_PACKAGE_ACL),y) SAMBA4_CONF_OPTS += --with-acl-support
@@ -150,9 +151,4 @@ endef SAMBA4_POST_INSTALL_TARGET_HOOKS += SAMBA4_REMOVE_SMBTORTURE endif -define SAMBA4_INSTALL_INIT_SYSV - $(INSTALL) -m 0755 -D package/samba4/S91smb \ - $(TARGET_DIR)/etc/init.d/S91smb -endef - $(eval $(generic-package))
package/samba4/smbd.run new file +3 -0
@@ -0,0 +1,3 @@ +description: Samba SMB daemon +prestart: mkdir -p /var/log/samba +foreground: /usr/sbin/smbd -F
Signature · 1 line
2.0.3
RFC v2 5/6 gpsd: common service startup
In reply to Alex SuykovThis package needs variable substitution in its .run file.
--- package/gpsd/S50gpsd | 40 ---------------------------------------- package/gpsd/gpsd.mk | 9 ++++++--- package/gpsd/gpsd.run | 3 +++ 3 files changed, 9 insertions(+), 43 deletions(-) delete mode 100644 package/gpsd/S50gpsd create mode 100644 package/gpsd/gpsd.run
package/gpsd/S50gpsd deleted +0 -40
@@ -1,40 +0,0 @@ -#!/bin/sh -# -# Starts the gps daemon. -# - -NAME=gpsd -DAEMON=/usr/sbin/$NAME -DEVICES=/dev/ttyS1 -PIDFILE=/var/run/$NAME.pid - -start() { - echo -n "Starting $NAME: " - start-stop-daemon -S -q -p $PIDFILE --exec $DAEMON -- -P $PIDFILE $DEVICES && echo "OK" || echo "Failed" -} -stop() { - echo -n "Stopping $NAME: " - start-stop-daemon -K -q -p $PIDFILE && echo "OK" || echo "Failed" - rm -f $PIDFILE -} -restart() { - stop - start -} - -case "$1" in - start) - start - ;; - stop) - stop - ;; - restart|reload) - restart - ;; - *) - echo "Usage: $0 {start|stop|restart}" - exit 1 -esac - -exit $?
package/gpsd/gpsd.mk +6 -3
@@ -208,10 +208,13 @@ define GPSD_INSTALL_TARGET_CMDS install) endef -define GPSD_INSTALL_INIT_SYSV - $(INSTALL) -m 0755 -D package/gpsd/S50gpsd $(TARGET_DIR)/etc/init.d/S50gpsd - $(SED) 's,^DEVICES=.*,DEVICES=$(BR2_PACKAGE_GPSD_DEVICES),' $(TARGET_DIR)/etc/init.d/S50gpsd +ifdef BR2_PACKAGE_GPSD_DEVICES +define GPSD_INSTALL_INIT + cp package/gpsd/gpsd.run $(@D)/gpsd.run + $(SED) "s!DEVICES!$(call qstrip,$(BR2_PACKAGE_GPSD_DEVICES))!" $(@D)/gpsd.run + support/init/install $(BR2_INIT) $(TARGET_DIR) $(@D)/gpsd.run endef +endif define GPSD_INSTALL_STAGING_CMDS (cd $(@D); \
package/gpsd/gpsd.run new file +3 -0
@@ -0,0 +1,3 @@ +description: GPS daemon +foreground: /usr/sbin/gpsd -N DEVICES +background: /usr/sbin/gpsd DEVICES
Signature · 1 line
2.0.3
RFC v2 6/6 acpid: common service startup
In reply to Alex SuykovSkipping systemd installation.
--- package/acpid/S02acpid | 22 ---------------------- package/acpid/acpid.mk | 8 +++----- package/acpid/acpid.run | 3 +++ 3 files changed, 6 insertions(+), 27 deletions(-) delete mode 100755 package/acpid/S02acpid create mode 100644 package/acpid/acpid.run
package/acpid/S02acpid deleted +0 -22
@@ -1,22 +0,0 @@ -#!/bin/sh - -case "$1" in - start) - echo -n "Starting acpid: " - start-stop-daemon -S -q -m -b -p /var/run/acpid.pid --exec /usr/sbin/acpid -- -n - [ $? = 0 ] && echo "OK" || echo "FAIL" - ;; - stop) - echo -n "Stopping acpid: " - start-stop-daemon -K -q -p /var/run/acpid.pid - [ $? = 0 ] && echo "OK" || echo "FAIL" - ;; - restart) - "$0" stop - sleep 1 - "$0" start - ;; - *) - echo "Usage: $0 {start|stop|restart}" - ;; -esac
package/acpid/acpid.mk +3 -5
@@ -9,11 +9,9 @@ ACPID_SOURCE = acpid-$(ACPID_VERSION).tar.xz ACPID_SITE = http://downloads.sourceforge.net/project/acpid2 ACPID_LICENSE = GPLv2+ ACPID_LICENSE_FILES = COPYING - -define ACPID_INSTALL_INIT_SYSV - $(INSTALL) -D -m 0755 package/acpid/S02acpid \ - $(TARGET_DIR)/etc/init.d/S02acpid -endef +ifndef BR2_INIT_SYSTEMD +ACPID_INIT_RUN = acpid.run +endif define ACPID_SET_EVENTS mkdir -p $(TARGET_DIR)/etc/acpi/events
package/acpid/acpid.run new file +3 -0
@@ -0,0 +1,3 @@ +description: ACPI daemon +foreground: /usr/sbin/acpid -f -n +background: /usr/sbin/acpid -n
Signature · 1 line
2.0.3
v2 cover common service startup files
In reply to Alex SuykovDear Alex Suykov,
Quoted 3 lines · Alex Suykov
This series is intended to simplify and clean up installation routine for daemon-like applications, merging sysv and systemd startup files and moving much of the common code out of per-package .mk files.
Thanks a lot for working on this.
To be honest, my feeling is that I don't really like Buildroot to invent its own "abstract" language to describe the initialization of services, then used to generate SysV and Systemd unit files.
There are two main reasons for this feeling.
First of all, because the philosophy of Buildroot is to not invent new language, or add layers on top of what exists: we use Kconfig for the configuration, make for the package building logic, shell and Python scripts in some situations. This is all standard, and generally well known by most Linux developers. Even though the language you propose for describing the initialization of services is certainly not very complicated, it remains a layer on top of what really happens.
Second, such abstract languages usually appear simple initially. But then, some corner cases show up, with cases that can easily be solved in shell scripts or systemd unit files, but were not planned in this small abstract language. So it has to be extended. Again, and again. To finally become as complicated as the shell scripts or systemd unit files.
Of course, my opinion is just one amongst many other Buildroot developers, and if all other Buildroot developers are convinced that this is the way to go, then we'll do it. But since not many people gave their opinion about this, I thought I would simply give mine.
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
v2 cover common service startup files
Alex, Thomas, All,
On 2015-04-06 10:51 +0200, Thomas Petazzoni spake thusly:
Quoted 10 lines · Alex Suykov
Quoted 3 lines
This series is intended to simplify and clean up installation routine for daemon-like applications, merging sysv and systemd startup files and moving much of the common code out of per-package .mk files.
Thanks a lot for working on this.
To be honest, my feeling is that I don't really like Buildroot to invent its own "abstract" language to describe the initialization of services, then used to generate SysV and Systemd unit files.
Totally agreed on my side.
Quoted 10 lines
There are two main reasons for this feeling.
First of all, because the philosophy of Buildroot is to not invent new language, or add layers on top of what exists: we use
Kconfigfor the configuration, make for the package building logic, shell and Python scripts in some situations. This is all standard, and generally well known by most Linux developers. Even though the language you propose for describing the initialization of services is certainly not very complicated, it remains a layer on top of what really happens.
Quoted 6 lines
Second, such abstract languages usually appear simple initially. But then, some corner cases show up, with cases that can easily be solved in shell scripts or systemd unit files, but were not planned in this small abstract language. So it has to be extended. Again, and again. To finally become as complicated as the shell scripts or systemd unit files.
Been there, done that. Indeed.
Quoted 4 lines
Of course, my opinion is just one amongst many other Buildroot developers, and if all other Buildroot developers are convinced that this is the way to go, then we'll do it. But since not many people gave their opinion about this, I thought I would simply give mine.
Well, it's always difficult to state an opinion on such a series. I have the gut-feeling that it is "not good", but just stating so is not sufficient to coment on it. You've expressed quite nicely my feelings bout this. Thanks!
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
v2 cover common service startup files
In reply to Thomas PetazzoniQuoted 3 lines
To be honest, my feeling is that I don't really like Buildroot to invent its own "abstract" language to describe the initialization of services, then used to generate SysV and Systemd unit files.
Seconded, from the currently-using-systemd camp. One of the nice things about systemd is getting to use upstream service files as much as possible, rather than having to maintain our own.
v2 cover common service startup files
In reply to Alex SuykovDear Alex Suykov,
Quoted 18 lines · Alex Suykov
This series is intended to simplify and clean up installation routine for daemon-like applications, merging sysv and systemd startup files and moving much of the common code out of per-package .mk files.
Currently buildroot requires pre-crafted sysv and/or systemd startup files to be supplied for each package that needs its daemon-like processes started at system boot. In many cases, this is redundant.
Only a small part of the startup scripts is package-specific. A single command, the one that starts the process in foreground mode, is typically enough to generate usable sysv and systemd startup files.
Separating package-specific data and removing the rest from package directories allows changing common code without the need to patch several dozen packages, ensures more or less even support for sysv and systemd, and potentially simplifies introduction of alternative system startup schemes.
Quoted 4 lines
The first patch in the series contains the common code, and the rest show how it affects individual packages. I'm only posting a few interesting ones with comments; the full set (~50 patches) is available
here: https://github.com/arsv/br/ branch run-1.
Thanks for this proposal. However, as you have seen, the general feedback was not very positive. We don't really like having a specialized language being created for Buildroot, so the overall approach doesn't really match the "spirit" of how things are done in Buildroot.
I've marked the corresponding patches as rejected in our patch tracking system.
Thanks for your contribution!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
v2 cover common service startup files
Quoted 8 lines · Thomas Petazzoni
Thanks for this proposal. However, as you have seen, the general feedback was not very positive. We don't really like having a specialized language being created for Buildroot, so the overall approach doesn't really match the "spirit" of how things are done in Buildroot.
I've marked the corresponding patches as rejected in our patch tracking system.
Ok, yeah, the initial reaction was pretty clear and I thought it has been marked as rejected for several weeks already. Looks like it wasn't, so people got those patch reminders and started replying.
-*--
And a kind of follow-up: I've got a bunch of systemd service files as a by-product of this effort, some of them for packages that have no systemd hooks at present.
If you're interested, I could either upload them somewhere for you to pick up, or alternatively start sending patches myself. One package at a time, without any global infrastructure changes.
v2 cover common service startup files
Quoted 17 lines · Alex Suykov
Quoted 8 lines · Thomas Petazzoni
Thanks for this proposal. However, as you have seen, the general feedback was not very positive. We don't really like having a specialized language being created for Buildroot, so the overall approach doesn't really match the "spirit" of how things are done in Buildroot.
I've marked the corresponding patches as rejected in our patch tracking system.
Ok, yeah, the initial reaction was pretty clear and I thought it has been marked as rejected for several weeks already. Looks like it wasn't, so people got those patch reminders and started replying.
-*--
Quoted 7 lines
And a kind of follow-up: I've got a bunch of systemd service files as a by-product of this effort, some of them for packages that have no systemd hooks at present.
If you're interested, I could either upload them somewhere for you to pick up, or alternatively start sending patches myself. One package at a time, without any global infrastructure changes.
That would be great!
Regards,
Arnout
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F