| Message ID | 20191029100113.27287-2-adrian.freihofer@siemens.com |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | simplify swupdate config | expand |
Hi Adrian, On 29/10/19 11:01, Adrian Freihofer wrote: > For most projects starting swupdate requires some logic implemented > in shell scripts. Therefore swupdate is now started by a shell script > also in case of systemd is anabled in DISTRO_FEATURES. > > The new swupdate startup script sources code snippets located in > /usr/lib/swupdate/conf.d and in /etc/swupdate/conf.d. The snippets are > executed in alphabetical order. The idea is that files in /usr are added > at build time and files in /etc might be added or modified at run-time. > If two scripts, one in /etc and one in /usr have the same file name, the > script in /usr gets skipped completely. This allows to disable code in > /usr, which is probably mounted ro, at runtime. > > Code snippets are automatically generated at build-time, depending on > the configuration created by swupdate's menuconfig. But code snippets > may be created manually and added via bbappend to the > /usr/lib/swupdate/conf.d folder. > > All modes (file, webserver, webclient) of swupdate are supported. > Different variables might be defined by the code snippets added to the > named folders: > - SWUPDATE_ARGS > - SWUPDATE_WEBSERVER_ARGS > - SWUPDATE_DOWNLOAD_ARGS > > Finally swupdate gets started by a line similar to: > > exec /usr/bin/swupdate $SWUPDATE_ARGS \ > -w "$SWUPDATE_WEBSERVER_ARGS" \ > -u "$SWUPDATE_DOWNLOAD_ARGS" > > The default set of configuraton and service files is now installed by > the "make install" target of the swupdate Makefile. The service files > which are not used for the latest git version of swupdate are moved > to swupdate-2019.04 folder. > > fixes in do_install > > This changes the filenames of the tools binaries for several reasons: > - Binaries should not be named "client" or "progress" > (also not accepted by Debian upstream) > - Inconsistent with names referred in the service files > > The swupdate_tools.inc file gets merged into swupdate.inc file. By > removing the tools file some bugs are fixed: > - The tools binaries were installed twice. > - do_compile from swupdate.inc was over written resulting in wired > behavior > - swupdate-progress.service file was part of swupdate package were the > corresponding swupdate-progress binary was part of the tools package. > > The tools are now installed by the "make install" target of swupdate's > Makefile. The related code here in meta-swupdate gets removed. > > Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> > --- > .../swupdate-progress.service | 0 > .../swupdate-usb.rules | 0 > .../swupdate-usb@.service | 0 > .../swupdate.service | 0 > .../systemd-tmpfiles-swupdate.conf | 0 > recipes-support/swupdate/swupdate.inc | 68 ++++++++++++---------- > recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++++- > recipes-support/swupdate/swupdate_git.bb | 5 +- > recipes-support/swupdate/swupdate_tools.inc | 24 -------- > 9 files changed, 69 insertions(+), 56 deletions(-) > rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%) > rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%) > rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%) > rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%) > rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%) > delete mode 100644 recipes-support/swupdate/swupdate_tools.inc > > diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service > similarity index 100% > rename from recipes-support/swupdate/swupdate/swupdate-progress.service > rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service > diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules > similarity index 100% > rename from recipes-support/swupdate/swupdate/swupdate-usb.rules > rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules > diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service > similarity index 100% > rename from recipes-support/swupdate/swupdate/swupdate-usb@.service > rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service > diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service > similarity index 100% > rename from recipes-support/swupdate/swupdate/swupdate.service > rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service > diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf > similarity index 100% > rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf > rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf > diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc > index 392af31..1e4f92e 100644 > --- a/recipes-support/swupdate/swupdate.inc > +++ b/recipes-support/swupdate/swupdate.inc > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig > SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \ > file://defconfig \ > file://swupdate \ > - file://swupdate.service \ > - file://swupdate-usb.rules \ > - file://swupdate-usb@.service \ > - file://swupdate-progress.service \ > - file://systemd-tmpfiles-swupdate.conf \ > " > > +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools" > INSANE_SKIP_${PN} = "ldflags" > -PACKAGES =+ "${PN}-www ${PN}-lua" > +INSANE_SKIP_${PN}-tools = "ldflags" > > FILES_${PN}-lua += "${libdir}/lua/" > -FILES_${PN}-www = "/www/*" > -FILES_${PN} += "${libdir}/tmpfiles.d" > +FILES_${PN}-www = " \ > + ${libdir}/swupdate/conf.d/*mongoose* \ > + /www/* \ > +" > +FILES_${PN}-tools = " \ > + ${bindir}/swupdate-client \ > + ${bindir}/swupdate-progress \ > + ${systemd_system_unitdir}/swupdate-progress.service \ > + ${bindir}/swupdate-hawkbitcfg \ > + ${bindir}/swupdate-sendtohawkbit \ > +" > +FILES_${PN} += " \ > + ${libdir}/tmpfiles.d \ > + ${libdir}/swupdate/* \ > + ${systemd_system_unitdir}/swupdate.socket \ > + ${systemd_system_unitdir}/swupdate.service \ > + ${systemd_system_unitdir}/swupdate-usb@.service \ > +" > > S = "${WORKDIR}/git/" > > @@ -116,17 +128,21 @@ python () { > } > > do_configure () { > - cp ${WORKDIR}/defconfig ${S}/.config > - merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > - cml1_do_configure > + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then I think this is not correct. Even if systemd is listed in the features for DISTRO, a user can select SystemV as init manager. The check should be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO. > + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config > + echo "# Global settings from swupdate recipe" >> ${S}/.config > + echo "CONFIG_SYSTEMD=y" >> ${S}/.config > + echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config I understand the logic, but I have an understanding problem. In fact, who is the master ? In current implementation, defconfig is the master. If a user run "bitbake -c menuconfig swupdate" or add fragments to the configuration, this becomes the master. In fact, the current recipes do not try to change defconfig, but set OE to reflect the values in defconfig. This is the reason for the anonymous python function in swupdate.inc. This adds DEPENDS to the list, quite an exception in OE. Because the list of depends can be short or long, on depends of the configuration. However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD comes from defconfig. But should not be responsibility of the user to set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ? > + else > + cp ${WORKDIR}/defconfig ${S}/.config > + fi > + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > + cml1_do_configure > } > > do_compile() { > unset LDFLAGS > - oe_runmake swupdate_unstripped progress_unstripped > - cp swupdate_unstripped swupdate > - cp progress_unstripped progress > - > + oe_runmake > } > > do_install () { > @@ -142,23 +158,15 @@ do_install () { > > install -d ${D}${sysconfdir}/init.d > install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d > - > - install -d ${D}${systemd_unitdir}/system > - install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_unitdir}/system > - install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_unitdir}/system > - install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_unitdir}/system > - > - > - if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then > - install -d ${D}${libdir}/tmpfiles.d > - install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf > - install -d ${D}${sysconfdir}/udev/rules.d > - install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/ > - fi > } > > INITSCRIPT_NAME = "swupdate" > INITSCRIPT_PARAMS = "defaults 70" > > -SYSTEMD_SERVICE_${PN} = "swupdate.service" > -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service swupdate-progress.service" A question that was raised more as one time on this list is if we have to split services into different packages. Not only swupdate-progress, but what about if a USB update is forbidden on the target ? A project should be able to decide which services should be installed and which not. > +SYSTEMD_SERVICE_${PN} = " \ > + swupdate.service \ > + swupdate-usb@.service \ > + " > + > +SYSTEMD_PACKAGES_append = " ${PN}-tools" > +SYSTEMD_SERVICE_${PN}-tools = "swupdate-progress.service" > diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb > index e2eabbb..5b0fb78 100644 > --- a/recipes-support/swupdate/swupdate_2019.04.bb > +++ b/recipes-support/swupdate/swupdate_2019.04.bb > @@ -1,4 +1,30 @@ > require swupdate.inc > -require swupdate_tools.inc > + > +SRC_URI += " \ > + file://swupdate.service \ > + file://swupdate-usb.rules \ > + file://swupdate-usb@.service \ > + file://swupdate-progress.service \ > + file://systemd-tmpfiles-swupdate.conf \ > + " > > SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81" > + > +do_install_append () { > + # Rename the binaries installed by make install > + test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress ${D}${bindir}/swupdate-progress > + test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client > + test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg > + test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit > + > + install -d ${D}${systemd_system_unitdir} > + install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir} > + install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir} > + install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir} > + if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then > + install -d ${D}${libdir}/tmpfiles.d > + install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf > + install -d ${D}${sysconfdir}/udev/rules.d > + install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/ > + fi > +} > diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb > index 9fea83a..8eef04e 100644 > --- a/recipes-support/swupdate/swupdate_git.bb > +++ b/recipes-support/swupdate/swupdate_git.bb > @@ -1,7 +1,10 @@ > require swupdate.inc > -require swupdate_tools.inc > > DEFAULT_PREFERENCE = "-1" > > SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85" > PV = "2019.04+git${SRCPV}" > + > +SYSTEMD_SERVICE_${PN} += " \ > + swupdate.socket \ > +" > diff --git a/recipes-support/swupdate/swupdate_tools.inc b/recipes-support/swupdate/swupdate_tools.inc > deleted file mode 100644 > index d270dd4..0000000 > --- a/recipes-support/swupdate/swupdate_tools.inc > +++ /dev/null > @@ -1,24 +0,0 @@ > -PACKAGES =+ "${PN}-tools" > - > -INSANE_SKIP_${PN}-tools = "ldflags" > - > -FILES_${PN}-tools = "${bindir}/swupdate-client \ > - ${bindir}/swupdate-progress \ > - ${bindir}/swupdate-hawkbitcfg \ > - ${bindir}/swupdate-sendtohawkbit" > - > -do_compile() { > - unset LDFLAGS > - > - oe_runmake > - cp swupdate_unstripped swupdate > -} > - > -do_install_append () { > - > - install -m 0755 tools/client_unstripped ${D}${bindir}/swupdate-client > - install -m 0755 tools/progress_unstripped ${D}${bindir}/swupdate-progress > - install -m 0755 tools/hawkbitcfg_unstripped ${D}${bindir}/swupdate-hawkbitcfg > - install -m 0755 tools/sendtohawkbit_unstripped ${D}${bindir}/swupdate-sendtohawkbit > - > -} > Agree to remove swupdate-tools.inc, it was introduced once to be compatible with previous versions. We do not need to bother anymore. Best regards, Stefano
Hi Stefano Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic: > > Hi Adrian, > > On 29/10/19 11:01, Adrian Freihofer wrote: > > For most projects starting swupdate requires some logic implemented > > in shell scripts. Therefore swupdate is now started by a shell script > > also in case of systemd is anabled in DISTRO_FEATURES. > > > > The new swupdate startup script sources code snippets located in > > /usr/lib/swupdate/conf.d and in /etc/swupdate/conf.d. The snippets are > > executed in alphabetical order. The idea is that files in /usr are added > > at build time and files in /etc might be added or modified at run-time. > > If two scripts, one in /etc and one in /usr have the same file name, the > > script in /usr gets skipped completely. This allows to disable code in > > /usr, which is probably mounted ro, at runtime. > > > > Code snippets are automatically generated at build-time, depending on > > the configuration created by swupdate's menuconfig. But code snippets > > may be created manually and added via bbappend to the > > /usr/lib/swupdate/conf.d folder. > > > > All modes (file, webserver, webclient) of swupdate are supported. > > Different variables might be defined by the code snippets added to the > > named folders: > > - SWUPDATE_ARGS > > - SWUPDATE_WEBSERVER_ARGS > > - SWUPDATE_DOWNLOAD_ARGS > > > > Finally swupdate gets started by a line similar to: > > > > exec /usr/bin/swupdate $SWUPDATE_ARGS \ > > -w "$SWUPDATE_WEBSERVER_ARGS" \ > > -u "$SWUPDATE_DOWNLOAD_ARGS" > > > > The default set of configuraton and service files is now installed by > > the "make install" target of the swupdate Makefile. The service files > > which are not used for the latest git version of swupdate are moved > > to swupdate-2019.04 folder. > > > > fixes in do_install > > > > This changes the filenames of the tools binaries for several reasons: > > - Binaries should not be named "client" or "progress" > > (also not accepted by Debian upstream) > > - Inconsistent with names referred in the service files > > > > The swupdate_tools.inc file gets merged into swupdate.inc file. By > > removing the tools file some bugs are fixed: > > - The tools binaries were installed twice. > > - do_compile from swupdate.inc was over written resulting in wired > > behavior > > - swupdate-progress.service file was part of swupdate package were the > > corresponding swupdate-progress binary was part of the tools package. > > > > The tools are now installed by the "make install" target of swupdate's > > Makefile. The related code here in meta-swupdate gets removed. > > > > Signed-off-by: Adrian Freihofer <adrian....@siemens.com <javascript:>> > > --- > > .../swupdate-progress.service | 0 > > .../swupdate-usb.rules | 0 > > .../swupdate-usb@.service | 0 > > .../swupdate.service | 0 > > .../systemd-tmpfiles-swupdate.conf | 0 > > recipes-support/swupdate/swupdate.inc | 68 > ++++++++++++---------- > > recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++++- > > recipes-support/swupdate/swupdate_git.bb | 5 +- > > recipes-support/swupdate/swupdate_tools.inc | 24 -------- > > 9 files changed, 69 insertions(+), 56 deletions(-) > > rename recipes-support/swupdate/{swupdate => > swupdate-2019.04}/swupdate-progress.service (100%) > > rename recipes-support/swupdate/{swupdate => > swupdate-2019.04}/swupdate-usb.rules (100%) > > rename recipes-support/swupdate/{swupdate => > swupdate-2019.04}/swupdate-usb@.service (100%) > > rename recipes-support/swupdate/{swupdate => > swupdate-2019.04}/swupdate.service (100%) > > rename recipes-support/swupdate/{swupdate => > swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%) > > delete mode 100644 recipes-support/swupdate/swupdate_tools.inc > > > > diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service > b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service > > similarity index 100% > > rename from recipes-support/swupdate/swupdate/swupdate-progress.service > > rename to > recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service > > diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules > b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules > > similarity index 100% > > rename from recipes-support/swupdate/swupdate/swupdate-usb.rules > > rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules > > diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service > b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service > > similarity index 100% > > rename from recipes-support/swupdate/swupdate/swupdate-usb@.service > > rename to > recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service > > diff --git a/recipes-support/swupdate/swupdate/swupdate.service > b/recipes-support/swupdate/swupdate-2019.04/swupdate.service > > similarity index 100% > > rename from recipes-support/swupdate/swupdate/swupdate.service > > rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service > > diff --git > a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf > b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf > > similarity index 100% > > rename from > recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf > > rename to > recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf > > diff --git a/recipes-support/swupdate/swupdate.inc > b/recipes-support/swupdate/swupdate.inc > > index 392af31..1e4f92e 100644 > > --- a/recipes-support/swupdate/swupdate.inc > > +++ b/recipes-support/swupdate/swupdate.inc > > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig > > SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \ > > file://defconfig \ > > file://swupdate \ > > - file://swupdate.service \ > > - file://swupdate-usb.rules \ > > - file://swupdate-usb@.service \ > > - file://swupdate-progress.service \ > > - file://systemd-tmpfiles-swupdate.conf \ > > " > > > > +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools" > > INSANE_SKIP_${PN} = "ldflags" > > -PACKAGES =+ "${PN}-www ${PN}-lua" > > +INSANE_SKIP_${PN}-tools = "ldflags" > > > > FILES_${PN}-lua += "${libdir}/lua/" > > -FILES_${PN}-www = "/www/*" > > -FILES_${PN} += "${libdir}/tmpfiles.d" > > +FILES_${PN}-www = " \ > > + ${libdir}/swupdate/conf.d/*mongoose* \ > > + /www/* \ > > +" > > +FILES_${PN}-tools = " \ > > + ${bindir}/swupdate-client \ > > + ${bindir}/swupdate-progress \ > > + ${systemd_system_unitdir}/swupdate-progress.service \ > > + ${bindir}/swupdate-hawkbitcfg \ > > + ${bindir}/swupdate-sendtohawkbit \ > > +" > > +FILES_${PN} += " \ > > + ${libdir}/tmpfiles.d \ > > + ${libdir}/swupdate/* \ > > + ${systemd_system_unitdir}/swupdate.socket \ > > + ${systemd_system_unitdir}/swupdate.service \ > > + ${systemd_system_unitdir}/swupdate-usb@.service \ > > +" > > > > S = "${WORKDIR}/git/" > > > > @@ -116,17 +128,21 @@ python () { > > } > > > > do_configure () { > > - cp ${WORKDIR}/defconfig ${S}/.config > > - merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > > - cml1_do_configure > > + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', > 'false', d)}; then > > I think this is not correct. Even if systemd is listed in the features > for DISTRO, a user can select SystemV as init manager. The check should > be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO. > Will be changed with v4, thanks. > > > + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config > > + echo "# Global settings from swupdate recipe" >> ${S}/.config > > + echo "CONFIG_SYSTEMD=y" >> ${S}/.config > > + echo > "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> > ${S}/.config > > I understand the logic, but I have an understanding problem. In fact, > who is the master ? > In current implementation, defconfig is the master. If a user run > "bitbake -c menuconfig swupdate" or add fragments to the configuration, > this becomes the master. In fact, the current recipes do not try to > change defconfig, but set OE to reflect the values in defconfig. This is > the reason for the anonymous python function in swupdate.inc. This adds > DEPENDS to the list, quite an exception in OE. Because the list of > depends can be short or long, on depends of the configuration. > > However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD > comes from defconfig. But should not be responsibility of the user to > set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ? > I have the same question. That's the reason why I initially came up with a different implementation. At least with Yocto, it does not make sense to ask the user about the systemd_system_unitdir variable which is in fact not configurable. The build system knows the variable. In this case, menuconfig just enables the user to break the build, without providing any flexibility. I would still prefer to pass systemd_system_unitdir directly to the make install target as an environment variable. However, I see the argument about passing variables to the configure step instead of passing a variable to the install step. But passing variables to the configure step seems not really supported by the kbuild build system. Patching the config file is probably the only way to define the variable during the configure step. I think the current implementation is not wrong and it could be merged. But we could also go back to the line of code in my first patch version. > > > + else > > + cp ${WORKDIR}/defconfig ${S}/.config > > + fi > > + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > > + cml1_do_configure > > } > > > > do_compile() { > > unset LDFLAGS > > - oe_runmake swupdate_unstripped progress_unstripped > > - cp swupdate_unstripped swupdate > > - cp progress_unstripped progress > > - > > + oe_runmake > > } > > > > do_install () { > > @@ -142,23 +158,15 @@ do_install () { > > > > install -d ${D}${sysconfdir}/init.d > > install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d > > - > > - install -d ${D}${systemd_unitdir}/system > > - install -m 644 ${WORKDIR}/swupdate.service > ${D}${systemd_unitdir}/system > > - install -m 644 ${WORKDIR}/swupdate-usb@.service > ${D}${systemd_unitdir}/system > > - install -m 644 ${WORKDIR}/swupdate-progress.service > ${D}${systemd_unitdir}/system > > - > > - > > - if > ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then > > - install -d ${D}${libdir}/tmpfiles.d > > - install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf > ${D}${libdir}/tmpfiles.d/swupdate.conf > > - install -d ${D}${sysconfdir}/udev/rules.d > > - install -m 0644 ${WORKDIR}/swupdate-usb.rules > ${D}${sysconfdir}/udev/rules.d/ > > - fi > > } > > > > INITSCRIPT_NAME = "swupdate" > > INITSCRIPT_PARAMS = "defaults 70" > > > > -SYSTEMD_SERVICE_${PN} = "swupdate.service" > > -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service > swupdate-progress.service" > > A question that was raised more as one time on this list is if we have > to split services into different packages. Not only swupdate-progress, > but what about if a USB update is forbidden on the target ? A project > should be able to decide which services should be installed and which not. > Shortly tried to implement that on top of this MR. It's easy, but not backward compatible. Therefore, I would like to discuss this in another MR. Probably not many users are following these details here any more. Thank you and regards, Adrian > +SYSTEMD_SERVICE_${PN} = " \ > > + swupdate.service \ > > + swupdate-usb@.service \ > > + " > > + > > +SYSTEMD_PACKAGES_append = " ${PN}-tools" > > +SYSTEMD_SERVICE_${PN}-tools = "swupdate-progress.service" > > diff --git a/recipes-support/swupdate/swupdate_2019.04.bb > b/recipes-support/swupdate/swupdate_2019.04.bb > > index e2eabbb..5b0fb78 100644 > > --- a/recipes-support/swupdate/swupdate_2019.04.bb > > +++ b/recipes-support/swupdate/swupdate_2019.04.bb > > @@ -1,4 +1,30 @@ > > require swupdate.inc > > -require swupdate_tools.inc > > + > > +SRC_URI += " \ > > + file://swupdate.service \ > > + file://swupdate-usb.rules \ > > + file://swupdate-usb@.service \ > > + file://swupdate-progress.service \ > > + file://systemd-tmpfiles-swupdate.conf \ > > + " > > > > SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81" > > + > > +do_install_append () { > > + # Rename the binaries installed by make install > > + test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress > ${D}${bindir}/swupdate-progress > > + test -f ${D}${bindir}/client && mv ${D}${bindir}/client > ${D}${bindir}/swupdate-client > > + test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg > ${D}${bindir}/swupdate-hawkbitcfg > > + test -f ${D}${bindir}/sendtohawkbit && mv > ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit > > + > > + install -d ${D}${systemd_system_unitdir} > > + install -m 644 ${WORKDIR}/swupdate.service > ${D}${systemd_system_unitdir} > > + install -m 644 ${WORKDIR}/swupdate-usb@.service > ${D}${systemd_system_unitdir} > > + install -m 644 ${WORKDIR}/swupdate-progress.service > ${D}${systemd_system_unitdir} > > + if > ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then > > + install -d ${D}${libdir}/tmpfiles.d > > + install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf > ${D}${libdir}/tmpfiles.d/swupdate.conf > > + install -d ${D}${sysconfdir}/udev/rules.d > > + install -m 0644 ${WORKDIR}/swupdate-usb.rules > ${D}${sysconfdir}/udev/rules.d/ > > + fi > > +} > > diff --git a/recipes-support/swupdate/swupdate_git.bb > b/recipes-support/swupdate/swupdate_git.bb > > index 9fea83a..8eef04e 100644 > > --- a/recipes-support/swupdate/swupdate_git.bb > > +++ b/recipes-support/swupdate/swupdate_git.bb > > @@ -1,7 +1,10 @@ > > require swupdate.inc > > -require swupdate_tools.inc > > > > DEFAULT_PREFERENCE = "-1" > > > > SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85" > > PV = "2019.04+git${SRCPV}" > > + > > +SYSTEMD_SERVICE_${PN} += " \ > > + swupdate.socket \ > > +" > > diff --git a/recipes-support/swupdate/swupdate_tools.inc > b/recipes-support/swupdate/swupdate_tools.inc > > deleted file mode 100644 > > index d270dd4..0000000 > > --- a/recipes-support/swupdate/swupdate_tools.inc > > +++ /dev/null > > @@ -1,24 +0,0 @@ > > -PACKAGES =+ "${PN}-tools" > > - > > -INSANE_SKIP_${PN}-tools = "ldflags" > > - > > -FILES_${PN}-tools = "${bindir}/swupdate-client \ > > - ${bindir}/swupdate-progress \ > > - ${bindir}/swupdate-hawkbitcfg \ > > - ${bindir}/swupdate-sendtohawkbit" > > - > > -do_compile() { > > - unset LDFLAGS > > - > > - oe_runmake > > - cp swupdate_unstripped swupdate > > -} > > - > > -do_install_append () { > > - > > - install -m 0755 tools/client_unstripped ${D}${bindir}/swupdate-client > > - install -m 0755 tools/progress_unstripped > ${D}${bindir}/swupdate-progress > > - install -m 0755 tools/hawkbitcfg_unstripped > ${D}${bindir}/swupdate-hawkbitcfg > > - install -m 0755 tools/sendtohawkbit_unstripped > ${D}${bindir}/swupdate-sendtohawkbit > > - > > -} > > > > Agree to remove swupdate-tools.inc, it was introduced once to be > compatible with previous versions. We do not need to bother anymore. > > Best regards, > Stefano > > -- > ===================================================================== > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de > <javascript:> > ===================================================================== >
Hi Adrian and Stefano, Am 02.11.19 um 22:48 schrieb adrian.freihofer@gmail.com: > Hi Stefano > > Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic: > > On 29/10/19 11:01, Adrian Freihofer wrote: [snip] > > diff --git a/recipes-support/swupdate/swupdate.inc > b/recipes-support/swupdate/swupdate.inc > > index 392af31..1e4f92e 100644 > > --- a/recipes-support/swupdate/swupdate.inc > > +++ b/recipes-support/swupdate/swupdate.inc > > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig > > SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https > <http://github.com/sbabic/swupdate.git;protocol=https> \ > > file://defconfig \ > > file://swupdate \ > > - file://swupdate.service \ > > - file://swupdate-usb.rules \ > > - file://swupdate-usb@.service \ > > - file://swupdate-progress.service \ > > - file://systemd-tmpfiles-swupdate.conf \ > > " > > > > +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools" > > INSANE_SKIP_${PN} = "ldflags" > > -PACKAGES =+ "${PN}-www ${PN}-lua" > > +INSANE_SKIP_${PN}-tools = "ldflags" > > > > FILES_${PN}-lua += "${libdir}/lua/" > > -FILES_${PN}-www = "/www/*" > > -FILES_${PN} += "${libdir}/tmpfiles.d" > > +FILES_${PN}-www = " \ > > + ${libdir}/swupdate/conf.d/*mongoose* \ > > + /www/* \ > > +" > > +FILES_${PN}-tools = " \ > > + ${bindir}/swupdate-client \ > > + ${bindir}/swupdate-progress \ > > + ${systemd_system_unitdir}/swupdate-progress.service \ > > + ${bindir}/swupdate-hawkbitcfg \ > > + ${bindir}/swupdate-sendtohawkbit \ > > +" > > +FILES_${PN} += " \ > > + ${libdir}/tmpfiles.d \ > > + ${libdir}/swupdate/* \ > > + ${systemd_system_unitdir}/swupdate.socket \ > > + ${systemd_system_unitdir}/swupdate.service \ > > + ${systemd_system_unitdir}/swupdate-usb@.service \ > > +" > > > > S = "${WORKDIR}/git/" > > > > @@ -116,17 +128,21 @@ python () { > > } > > > > do_configure () { > > - cp ${WORKDIR}/defconfig ${S}/.config > > - merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > > - cml1_do_configure > > + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', > 'true', 'false', d)}; then > > I think this is not correct. Even if systemd is listed in the features > for DISTRO, a user can select SystemV as init manager. The check should > be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO. > > Will be changed with v4, thanks. NACK. The init manager could be image specific. It is a common pattern do enable systemd support via DISTRO feature. We could use a variable like PACKAGECONFIG or a option like CONFIG_SYSTEMD in the defconfig to give the user the possibility to control it. The later leads to the problem that a distro feature (systemd) is controlled by machine specific file. > > + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > > ${S}/.config > > + echo "# Global settings from swupdate recipe" >> > ${S}/.config > > + echo "CONFIG_SYSTEMD=y" >> ${S}/.config > > + echo > "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> > ${S}/.config > > I understand the logic, but I have an understanding problem. In fact, > who is the master ? Usually the recipe is the master in OE but this is only partially true for kconfig recipes. > > > In current implementation, defconfig is the master. This is the problem because the defconfig couldn't depend on the distro and machine together. Furthermore it couldn't be influence by OE variables. > If a user run > "bitbake -c menuconfig swupdate" or add fragments to the configuration, > this becomes the master. In fact, the current recipes do not try to > change defconfig, but set OE to reflect the values in defconfig. > This is > the reason for the anonymous python function in swupdate.inc. This adds > DEPENDS to the list, quite an exception in OE. Because the list of > depends can be short or long, on depends of the configuration. What was the reason to use this exception instead of a list of PACKAGECONFIGs and a generated configuration? > However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD > comes from defconfig. But should not be responsibility of the user to > set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ? This option is managed by OE / distro and shouldn't be set via the user. Especially not via a machine specific and distro independent file. > I have the same question. That's the reason why I initially came up with > a different implementation. > At least with Yocto, it does not make sense to ask the user about the > systemd_system_unitdir variable which is in fact not configurable. This is a generic problem of distro specific configurations and meta build systems. How should the configuration tool knows that some configurations are managed by the meta build system? > The build system knows the variable. In this case, menuconfig just > enables the user to break the build, without providing any flexibility. We could use "sed" to replace the value in the .config or we could use a cfg file to make the problem visible to the user. > I would still prefer to pass systemd_system_unitdir directly to the > make install target as an environment variable. What would be next? We pass the LUAPKG directly to make and all system directories to make install? Please don't break common and widely-used rules because it is simple to do so. > However, I see the argument about passing variables to the configure > step instead of passing a variable to the install step. > But passing variables to the configure step seems not really supported > by the kbuild build system. This is the real problem and maybe the reason why OE create the configuration on the fly from the recipe for all other build tools (autotools, cmake, meson). Do we really need the menuconfig or could this be handled by a list of PACKAGECONFIGs? Maybe it is possible to hide some options in menuconfig when it is started by OE. > Patching the config file is probably the only way to define the variable > during the configure step. Other recipes do the same. > I think the current implementation is not wrong and it could be merged. > But we could also go back to the line of code in my first patch version. NACK > > > > + else > > + cp ${WORKDIR}/defconfig ${S}/.config > > + fi > > + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > > + cml1_do_configure > > } > > > > do_compile() { > > unset LDFLAGS > > - oe_runmake swupdate_unstripped progress_unstripped > > - cp swupdate_unstripped swupdate > > - cp progress_unstripped progress > > - > > + oe_runmake > > } > > > > do_install () { > > @@ -142,23 +158,15 @@ do_install () { > > > > install -d ${D}${sysconfdir}/init.d > > install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d > > - > > - install -d ${D}${systemd_unitdir}/system > > - install -m 644 ${WORKDIR}/swupdate.service > ${D}${systemd_unitdir}/system > > - install -m 644 ${WORKDIR}/swupdate-usb@.service > ${D}${systemd_unitdir}/system > > - install -m 644 ${WORKDIR}/swupdate-progress.service > ${D}${systemd_unitdir}/system > > - > > - > > - if > ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; > then > > - install -d ${D}${libdir}/tmpfiles.d > > - install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf > ${D}${libdir}/tmpfiles.d/swupdate.conf > > - install -d ${D}${sysconfdir}/udev/rules.d > > - install -m 0644 ${WORKDIR}/swupdate-usb.rules > ${D}${sysconfdir}/udev/rules.d/ > > - fi > > } > > > > INITSCRIPT_NAME = "swupdate" > > INITSCRIPT_PARAMS = "defaults 70" > > > > -SYSTEMD_SERVICE_${PN} = "swupdate.service" > > -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service > swupdate-progress.service" > > A question that was raised more as one time on this list is if we have > to split services into different packages. Not only swupdate-progress, > but what about if a USB update is forbidden on the target ? A project > should be able to decide which services should be installed and > which not. > > Shortly tried to implement that on top of this MR. It's easy, but not > backward compatible. > Therefore, I would like to discuss this in another MR. Probably not many > users are following these details here any more. ACK Regards Stefan
Hi Stefan, Adrian, On 03/11/19 09:48, Stefan Herbrechtsmeier wrote: > Hi Adrian and Stefano, > > Am 02.11.19 um 22:48 schrieb adrian.freihofer@gmail.com: >> Hi Stefano >> >> Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic: >> >> On 29/10/19 11:01, Adrian Freihofer wrote: > > [snip] > >> > diff --git a/recipes-support/swupdate/swupdate.inc >> b/recipes-support/swupdate/swupdate.inc >> > index 392af31..1e4f92e 100644 >> > --- a/recipes-support/swupdate/swupdate.inc >> > +++ b/recipes-support/swupdate/swupdate.inc >> > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig >> > SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https >> <http://github.com/sbabic/swupdate.git;protocol=https> \ >> > file://defconfig \ >> > file://swupdate \ >> > - file://swupdate.service \ >> > - file://swupdate-usb.rules \ >> > - file://swupdate-usb@.service \ >> > - file://swupdate-progress.service \ >> > - file://systemd-tmpfiles-swupdate.conf \ >> > " >> > >> > +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools" >> > INSANE_SKIP_${PN} = "ldflags" >> > -PACKAGES =+ "${PN}-www ${PN}-lua" >> > +INSANE_SKIP_${PN}-tools = "ldflags" >> > >> > FILES_${PN}-lua += "${libdir}/lua/" >> > -FILES_${PN}-www = "/www/*" >> > -FILES_${PN} += "${libdir}/tmpfiles.d" >> > +FILES_${PN}-www = " \ >> > + ${libdir}/swupdate/conf.d/*mongoose* \ >> > + /www/* \ >> > +" >> > +FILES_${PN}-tools = " \ >> > + ${bindir}/swupdate-client \ >> > + ${bindir}/swupdate-progress \ >> > + ${systemd_system_unitdir}/swupdate-progress.service \ >> > + ${bindir}/swupdate-hawkbitcfg \ >> > + ${bindir}/swupdate-sendtohawkbit \ >> > +" >> > +FILES_${PN} += " \ >> > + ${libdir}/tmpfiles.d \ >> > + ${libdir}/swupdate/* \ >> > + ${systemd_system_unitdir}/swupdate.socket \ >> > + ${systemd_system_unitdir}/swupdate.service \ >> > + ${systemd_system_unitdir}/swupdate-usb@.service \ >> > +" >> > >> > S = "${WORKDIR}/git/" >> > >> > @@ -116,17 +128,21 @@ python () { >> > } >> > >> > do_configure () { >> > - cp ${WORKDIR}/defconfig ${S}/.config >> > - merge_config.sh -m .config ${@" ".join(find_cfgs(d))} >> > - cml1_do_configure >> > + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', >> 'true', 'false', d)}; then >> >> I think this is not correct. Even if systemd is listed in the >> features >> for DISTRO, a user can select SystemV as init manager. The check >> should >> be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO. >> >> Will be changed with v4, thanks. > > NACK. The init manager could be image specific. You are right - this is also a common pattern. > It is a common pattern > do enable systemd support via DISTRO feature. Enable is one point, if systemd is active is another point, and a package cannot know (and should be unaware) which init manager will run. It should provide support for both. > We could use a variable > like PACKAGECONFIG or a option like CONFIG_SYSTEMD in the defconfig to > give the user the possibility to control it. But then we want to add dependencies between SWUpdate as project itself and the environment (with or without systemd) where it will run. SWUpdate should be unaware of it. What about to install always systemd related files but put them in a sparate package (swupdate-systemd) ? > The later leads to the > problem that a distro feature (systemd) is controlled by machine > specific file. Not always. What about if systemd is in DISTRO_FEATURES for my own distro (in my layer), but I need to build an image for another distro, for example: DISTRO=mydistro bitbake my-imgae DISTRO=poky bitbake my-imgae Poky uses as default SystemV, my-distro (set in one of configuration file) sets systemd. The above example is not built, it makes sense with SWUpdate in case of rescue image because systemd adds a significant overload. > >> > + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > >> ${S}/.config >> > + echo "# Global settings from swupdate recipe" >> >> ${S}/.config >> > + echo "CONFIG_SYSTEMD=y" >> ${S}/.config >> > + echo >> "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> >> ${S}/.config >> >> I understand the logic, but I have an understanding problem. In fact, >> who is the master ? > > Usually the recipe is the master in OE but this is only partially true > for kconfig recipes. I would say it is not true - see kernel class and build for busybox. IMHO in these cases the defconfig is the master. > >> >> >> In current implementation, defconfig is the master. > > This is the problem because the defconfig couldn't depend on the distro > and machine together. Furthermore it couldn't be influence by OE variables. > >> If a user run >> "bitbake -c menuconfig swupdate" or add fragments to the >> configuration, >> this becomes the master. In fact, the current recipes do not try to >> change defconfig, but set OE to reflect the values in defconfig. >> This is >> the reason for the anonymous python function in swupdate.inc. This >> adds >> DEPENDS to the list, quite an exception in OE. Because the list of >> depends can be short or long, on depends of the configuration. > > What was the reason to use this exception instead of a list of > PACKAGECONFIGs and a generated configuration? As far as I know this does not work together with defconfig and fragments. Using fragments is supported in meta-swupdate, as well as "bitbake -c menuconfig swupdate". If there is a solution to not break these workflow, we can take it. Please consider that OE is not the only buildsystem supported, even if a lot of changes are thought for OE and I confess I use OE for most of my projects (but not all..). Buildroot and debian are supported and must be supported in future, too. > >> However, the single case above seems "quite" ok to me. CONFIG_SYSTEMD >> comes from defconfig. But should not be responsibility of the user to >> set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ? > > This option is managed by OE / distro and shouldn't be set via the user. > Especially not via a machine specific and distro independent file. Shouldn't does not mean forbidden or that there are not cases where it makes sense. IMHO we have to split between CONFIG_ that are part of SWUPdate's configuration because internal behavior of SWUpdate changes (like CONFIG_SYSTEMD because notifications are sent), and CONFIG_ that define environmnet where SWUpdate will run, like CONFIG_SYSTEMD_SYSTEM_UNITDIR, because no changes in code is requested: this just install units into the system. > >> I have the same question. That's the reason why I initially came up >> with a different implementation. >> At least with Yocto, it does not make sense to ask the user about the >> systemd_system_unitdir variable which is in fact not configurable. > > This is a generic problem of distro specific configurations and meta > build systems. How should the configuration tool knows that some > configurations are managed by the meta build system? Right. > >> The build system knows the variable. In this case, menuconfig just >> enables the user to break the build, without providing any flexibility. > > We could use "sed" to replace the value in the .config or we could use a > cfg file to make the problem visible to the user. > >> I would still prefer to pass systemd_system_unitdir directly to the >> make install target as an environment variable. > > What would be next? We pass the LUAPKG directly to make and all system > directories to make install? > > Please don't break common and widely-used rules because it is simple to > do so. Not searching for easy solution, but also I do not want to break current workflow. > >> However, I see the argument about passing variables to the configure >> step instead of passing a variable to the install step. >> But passing variables to the configure step seems not really supported >> by the kbuild build system. > > This is the real problem Exactly. > and maybe the reason why OE create the > configuration on the fly from the recipe for all other build tools > (autotools, cmake, meson).> > Do we really need the menuconfig or could this be handled by a list of > PACKAGECONFIGs? See above. There were already a patch for PACKAGECONFIG, but it breaks using menuconfig and fragments. > > Maybe it is possible to hide some options in menuconfig when it is > started by OE. Mhhh...good idea. Ye, this is possible, too. > >> Patching the config file is probably the only way to define the >> variable during the configure step. > > Other recipes do the same. > >> I think the current implementation is not wrong and it could be >> merged. But we could also go back to the line of code in my first >> patch version. > > NACK > >> >> >> > + else >> > + cp ${WORKDIR}/defconfig ${S}/.config >> > + fi >> > + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} >> > + cml1_do_configure >> > } >> > >> > do_compile() { >> > unset LDFLAGS >> > - oe_runmake swupdate_unstripped progress_unstripped >> > - cp swupdate_unstripped swupdate >> > - cp progress_unstripped progress >> > - >> > + oe_runmake >> > } >> > >> > do_install () { >> > @@ -142,23 +158,15 @@ do_install () { >> > >> > install -d ${D}${sysconfdir}/init.d >> > install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d >> > - >> > - install -d ${D}${systemd_unitdir}/system >> > - install -m 644 ${WORKDIR}/swupdate.service >> ${D}${systemd_unitdir}/system >> > - install -m 644 ${WORKDIR}/swupdate-usb@.service >> ${D}${systemd_unitdir}/system >> > - install -m 644 ${WORKDIR}/swupdate-progress.service >> ${D}${systemd_unitdir}/system >> > - >> > - >> > - if >> ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; >> then >> > - install -d ${D}${libdir}/tmpfiles.d >> > - install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf >> ${D}${libdir}/tmpfiles.d/swupdate.conf >> > - install -d ${D}${sysconfdir}/udev/rules.d >> > - install -m 0644 ${WORKDIR}/swupdate-usb.rules >> ${D}${sysconfdir}/udev/rules.d/ >> > - fi >> > } >> > >> > INITSCRIPT_NAME = "swupdate" >> > INITSCRIPT_PARAMS = "defaults 70" >> > >> > -SYSTEMD_SERVICE_${PN} = "swupdate.service" >> > -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service >> swupdate-progress.service" >> >> A question that was raised more as one time on this list is if we >> have >> to split services into different packages. Not only >> swupdate-progress, >> but what about if a USB update is forbidden on the target ? A project >> should be able to decide which services should be installed and >> which not. >> >> Shortly tried to implement that on top of this MR. It's easy, but not >> backward compatible. >> Therefore, I would like to discuss this in another MR. Probably not >> many users are following these details here any more. > > ACK Ok, let's proceed in this way. Best regards, Stefano
Hi Stefano, hi Stefan
There are, in my opinion, two points which should be reconsidered.
1) Is kbuild the right build-system for swupdate?
The kbuild system is fine e.g. for the kernel or for uboot, but not ideal
for a user-space application such as swupdate.
With the kbuild system I do not know the "right" answers to the questions
we are currently discussing about. Compromises are required to proceed here.
Let's assume, there would be a cmake implementation providing a -D
parameter for each CONFIG_ option provided by the current kbuild based
implementation.
For Yocto, for each -D parameter, the corresponding PACKAGECONFIG option
needs to be provided.The default config could be defined like:
PACKAGECONFIG ?= "${SWUPDATE_PACKAGECONFIG_MACHINE}".
This would probably (I've not seen something similar so far) allow to
define the MACHINE specific parameters (e.g. CONFIG_UBOOT, CONFIG_MTD) in
the machine.conf files.
SWUPDATE_PACKAGECONFIG_MACHINE = "uboot mtd".
Distro specific flags (e.g. CONFIG_SURICATTA_HAWKBIT) could be enabled and
disabled in the distro.conf file.
PACKAGECONFIG_append_pn-swupdate = " suricatta-hawkbit"
This example is very Yocto specific. But the logic behind applies to other
distros and build systems as well.
2) The init system is image specific
I absolutely disagree.
The Init Manager is a variable defined at the DISTRO level, not at the
image level. Changing the init system has a potential impact on the build
steps of each package. These build steps are executed before the image is
assembled. They should therefore be the same for all images that can be
created with one DISTRO.
If a project requires two images, for example one with systemd and one with
busybox init, two DISTROs are required. Two DISTROs practically mean two
separate build folders. Only the sstate cache can be shared.
With recent Yocto versions "multiconfig" was introduced. As far as I
understand, it addresses exactly the use case we are discussing here.
This is probably also the reason why poky does not split packages for sysv
scripts and systemd service files. Splitting packages would solve just one
problem among many to make the init system an image-level configuration.
This also means that v4 of my patch is based on a misunderstanding, v3 was
better. I propose to merge v3 of:
- "swupdate: improve systemd config"
- "swupdate: simplify find images added to swu"
Please let us proceed with a pragmatic implementation and solve the more
fundamental problems later (e.g. kbuild or cmake or meson).
Please let us stop the discussion about fixing my patches to support
different init systems on image level. This is not how Yocto is supposed to
work.
Please let us focus on the best compromise to deal with kbuild. The
"perfect solution" is probably not possible with kbuild.
Thank you for your valuable feedback.
Best regards,
Adrian
Am Sonntag, 3. November 2019 11:41:15 UTC+1 schrieb Stefano Babic:
>
> Hi Stefan, Adrian,
>
> On 03/11/19 09:48, Stefan Herbrechtsmeier wrote:
> > Hi Adrian and Stefano,
> >
> > Am 02.11.19 um 22:48 schrieb adrian....@gmail.com <javascript:>:
> >> Hi Stefano
> >>
> >> Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic:
> >>
> >> On 29/10/19 11:01, Adrian Freihofer wrote:
> >
> > [snip]
> >
> >> > diff --git a/recipes-support/swupdate/swupdate.inc
> >> b/recipes-support/swupdate/swupdate.inc
> >> > index 392af31..1e4f92e 100644
> >> > --- a/recipes-support/swupdate/swupdate.inc
> >> > +++ b/recipes-support/swupdate/swupdate.inc
> >> > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig
> >> > SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https
> >> <http://github.com/sbabic/swupdate.git;protocol=https> \
> >> > file://defconfig \
> >> > file://swupdate \
> >> > - file://swupdate.service \
> >> > - file://swupdate-usb.rules \
> >> > - file://swupdate-usb@.service \
> >> > - file://swupdate-progress.service \
> >> > - file://systemd-tmpfiles-swupdate.conf \
> >> > "
> >> >
> >> > +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools"
> >> > INSANE_SKIP_${PN} = "ldflags"
> >> > -PACKAGES =+ "${PN}-www ${PN}-lua"
> >> > +INSANE_SKIP_${PN}-tools = "ldflags"
> >> >
> >> > FILES_${PN}-lua += "${libdir}/lua/"
> >> > -FILES_${PN}-www = "/www/*"
> >> > -FILES_${PN} += "${libdir}/tmpfiles.d"
> >> > +FILES_${PN}-www = " \
> >> > + ${libdir}/swupdate/conf.d/*mongoose* \
> >> > + /www/* \
> >> > +"
> >> > +FILES_${PN}-tools = " \
> >> > + ${bindir}/swupdate-client \
> >> > + ${bindir}/swupdate-progress \
> >> > + ${systemd_system_unitdir}/swupdate-progress.service \
> >> > + ${bindir}/swupdate-hawkbitcfg \
> >> > + ${bindir}/swupdate-sendtohawkbit \
> >> > +"
> >> > +FILES_${PN} += " \
> >> > + ${libdir}/tmpfiles.d \
> >> > + ${libdir}/swupdate/* \
> >> > + ${systemd_system_unitdir}/swupdate.socket \
> >> > + ${systemd_system_unitdir}/swupdate.service \
> >> > + ${systemd_system_unitdir}/swupdate-usb@.service \
> >> > +"
> >> >
> >> > S = "${WORKDIR}/git/"
> >> >
> >> > @@ -116,17 +128,21 @@ python () {
> >> > }
> >> >
> >> > do_configure () {
> >> > - cp ${WORKDIR}/defconfig ${S}/.config
> >> > - merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
> >> > - cml1_do_configure
> >> > + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd',
> >> 'true', 'false', d)}; then
> >>
> >> I think this is not correct. Even if systemd is listed in the
> >> features
> >> for DISTRO, a user can select SystemV as init manager. The check
> >> should
> >> be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO.
> >>
> >> Will be changed with v4, thanks.
> >
> > NACK. The init manager could be image specific.
>
> You are right - this is also a common pattern.
> It is a common pattern
> > do enable systemd support via DISTRO feature.
>
> Enable is one point, if systemd is active is another point, and a
> package cannot know (and should be unaware) which init manager will run.
> It should provide support for both.
>
> > We could use a variable
> > like PACKAGECONFIG or a option like CONFIG_SYSTEMD in the defconfig to
> > give the user the possibility to control it.
>
> But then we want to add dependencies between SWUpdate as project itself
> and the environment (with or without systemd) where it will run.
> SWUpdate should be unaware of it. What about to install always systemd
> related files but put them in a sparate package (swupdate-systemd) ?
>
> > The later leads to the
> > problem that a distro feature (systemd) is controlled by machine
> > specific file.
>
> Not always.
>
> What about if systemd is in DISTRO_FEATURES for my own distro (in my
> layer), but I need to build an image for another distro, for example:
>
> DISTRO=mydistro bitbake my-imgae
> DISTRO=poky bitbake my-imgae
>
> Poky uses as default SystemV, my-distro (set in one of configuration
> file) sets systemd. The above example is not built, it makes sense with
> SWUpdate in case of rescue image because systemd adds a significant
> overload.
>
> >
> >> > + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig >
> >> ${S}/.config
> >> > + echo "# Global settings from swupdate recipe" >>
> >> ${S}/.config
> >> > + echo "CONFIG_SYSTEMD=y" >> ${S}/.config
> >> > + echo
> >> "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >>
> >> ${S}/.config
> >>
> >> I understand the logic, but I have an understanding problem. In
> fact,
> >> who is the master ?
> >
> > Usually the recipe is the master in OE but this is only partially true
> > for kconfig recipes.
>
> I would say it is not true - see kernel class and build for busybox.
> IMHO in these cases the defconfig is the master.
>
> >
> >>
> >>
> >> In current implementation, defconfig is the master.
> >
> > This is the problem because the defconfig couldn't depend on the distro
> > and machine together. Furthermore it couldn't be influence by OE
> variables.
> >
> >> If a user run
> >> "bitbake -c menuconfig swupdate" or add fragments to the
> >> configuration,
> >> this becomes the master. In fact, the current recipes do not try to
> >> change defconfig, but set OE to reflect the values in defconfig.
> >> This is
> >> the reason for the anonymous python function in swupdate.inc. This
> >> adds
> >> DEPENDS to the list, quite an exception in OE. Because the list of
> >> depends can be short or long, on depends of the configuration.
> >
> > What was the reason to use this exception instead of a list of
> > PACKAGECONFIGs and a generated configuration?
>
> As far as I know this does not work together with defconfig and
> fragments. Using fragments is supported in meta-swupdate, as well as
> "bitbake -c menuconfig swupdate". If there is a solution to not break
> these workflow, we can take it.
>
> Please consider that OE is not the only buildsystem supported, even if a
> lot of changes are thought for OE and I confess I use OE for most of my
> projects (but not all..). Buildroot and debian are supported and must be
> supported in future, too.
>
>
> >> However, the single case above seems "quite" ok to me.
> CONFIG_SYSTEMD
> >> comes from defconfig. But should not be responsibility of the user
> to
> >> set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ?
> >
> > This option is managed by OE / distro and shouldn't be set via the user.
> > Especially not via a machine specific and distro independent file.
>
> Shouldn't does not mean forbidden or that there are not cases where it
> makes sense. IMHO we have to split between CONFIG_ that are part of
> SWUPdate's configuration because internal behavior of SWUpdate changes
> (like CONFIG_SYSTEMD because notifications are sent), and CONFIG_ that
> define environmnet where SWUpdate will run, like
> CONFIG_SYSTEMD_SYSTEM_UNITDIR, because no changes in code is requested:
> this just install units into the system.
>
> >
> >> I have the same question. That's the reason why I initially came up
> >> with a different implementation.
> >> At least with Yocto, it does not make sense to ask the user about the
> >> systemd_system_unitdir variable which is in fact not configurable.
> >
> > This is a generic problem of distro specific configurations and meta
> > build systems. How should the configuration tool knows that some
> > configurations are managed by the meta build system?
>
> Right.
>
> >
> >> The build system knows the variable. In this case, menuconfig just
> >> enables the user to break the build, without providing any flexibility.
> >
> > We could use "sed" to replace the value in the .config or we could use a
> > cfg file to make the problem visible to the user.
> >
> >> I would still prefer to pass systemd_system_unitdir directly to the
> >> make install target as an environment variable.
> >
> > What would be next? We pass the LUAPKG directly to make and all system
> > directories to make install?
> >
> > Please don't break common and widely-used rules because it is simple to
> > do so.
>
> Not searching for easy solution, but also I do not want to break current
> workflow.
>
> >
> >> However, I see the argument about passing variables to the configure
> >> step instead of passing a variable to the install step.
> >> But passing variables to the configure step seems not really supported
> >> by the kbuild build system.
> >
> > This is the real problem
>
> Exactly.
>
> > and maybe the reason why OE create the
> > configuration on the fly from the recipe for all other build tools
> > (autotools, cmake, meson).>
> > Do we really need the menuconfig or could this be handled by a list of
> > PACKAGECONFIGs?
>
> See above. There were already a patch for PACKAGECONFIG, but it breaks
> using menuconfig and fragments.
>
> >
> > Maybe it is possible to hide some options in menuconfig when it is
> > started by OE.
>
> Mhhh...good idea. Ye, this is possible, too.
>
> >
> >> Patching the config file is probably the only way to define the
> >> variable during the configure step.
> >
> > Other recipes do the same.
> >
> >> I think the current implementation is not wrong and it could be
> >> merged. But we could also go back to the line of code in my first
> >> patch version.
> >
> > NACK
> >
> >>
> >>
> >> > + else
> >> > + cp ${WORKDIR}/defconfig ${S}/.config
> >> > + fi
> >> > + merge_config.sh -m .config ${@" ".join(find_cfgs(d))}
> >> > + cml1_do_configure
> >> > }
> >> >
> >> > do_compile() {
> >> > unset LDFLAGS
> >> > - oe_runmake swupdate_unstripped progress_unstripped
> >> > - cp swupdate_unstripped swupdate
> >> > - cp progress_unstripped progress
> >> > -
> >> > + oe_runmake
> >> > }
> >> >
> >> > do_install () {
> >> > @@ -142,23 +158,15 @@ do_install () {
> >> >
> >> > install -d ${D}${sysconfdir}/init.d
> >> > install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d
> >> > -
> >> > - install -d ${D}${systemd_unitdir}/system
> >> > - install -m 644 ${WORKDIR}/swupdate.service
> >> ${D}${systemd_unitdir}/system
> >> > - install -m 644 ${WORKDIR}/swupdate-usb@.service
> >> ${D}${systemd_unitdir}/system
> >> > - install -m 644 ${WORKDIR}/swupdate-progress.service
> >> ${D}${systemd_unitdir}/system
> >> > -
> >> > -
> >> > - if
> >>
> ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
> >> then
> >> > - install -d ${D}${libdir}/tmpfiles.d
> >> > - install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf
> >> ${D}${libdir}/tmpfiles.d/swupdate.conf
> >> > - install -d ${D}${sysconfdir}/udev/rules.d
> >> > - install -m 0644 ${WORKDIR}/swupdate-usb.rules
> >> ${D}${sysconfdir}/udev/rules.d/
> >> > - fi
> >> > }
> >> >
> >> > INITSCRIPT_NAME = "swupdate"
> >> > INITSCRIPT_PARAMS = "defaults 70"
> >> >
> >> > -SYSTEMD_SERVICE_${PN} = "swupdate.service"
> >> > -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service
> >> swupdate-progress.service"
> >>
> >> A question that was raised more as one time on this list is if we
> >> have
> >> to split services into different packages. Not only
> >> swupdate-progress,
> >> but what about if a USB update is forbidden on the target ? A
> project
> >> should be able to decide which services should be installed and
> >> which not.
> >>
> >> Shortly tried to implement that on top of this MR. It's easy, but not
> >> backward compatible.
> >> Therefore, I would like to discuss this in another MR. Probably not
> >> many users are following these details here any more.
> >
> > ACK
>
> Ok, let's proceed in this way.
>
> Best regards,
> Stefano
>
> --
> =====================================================================
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> <javascript:>
> =====================================================================
>
Hi Stefano, hi Stefan
After thinking about everything for another hour, I remembered a project
(implemented by Stefano) which would break with my changes.
Installing always sysv and systemd scripts, but splitting the init system
related files to separate packages, would probably solve this specific
problem.
It would allow to build a big systemd based image and a minimal sysv based
rescue image out of one DISTRO.
However, the solution would be very special. The user would have to add
swupdate and one of swupdate-systemd or swupdate-svinit packages to the
image.
To simplify the default use case with one image, we could add something
like the following to the recipe:
# Set this variable to an empty string in a bbappend, if you need support
for sysv and systemd image based systems with one common swupdate build.
# This requires to explicitly add one of swupdate-sysv or swupdate-systemd
packages to IMAGE_INSTALL
SWUPDATE_ACTIVE_INIT ?= "${VIRTUAL-RUNTIME_init_manager}"
RDEPENDS_${PN} += "swupdate-${SWUPDATE_ACTIVE_INIT}"
If we slightly adapt the current sysv script to source the new
/usr/lib/swupdate/swupdate.sh script instead of directly calling the
swupdate binary, the sysv case would become more generic and more equal to
the systemd case. Basically only the socket-file, the service-file and the
init script would be split out, but not the new shell script snippets in
/usr/lib/swupdate.
What do you think? Should I send a v5 based on this idea?
Regards,
Adrian
Hi Adrian, On 03/11/19 18:22, adrian.freihofer@gmail.com wrote: > Hi Stefano, hi Stefan > > After thinking about everything for another hour, I remembered a project > (implemented by Stefano) which would break with my changes. You anticipate my answer - I wanted to write exactly this. > Installing always sysv and systemd scripts, but splitting the init > system related files to separate packages, would probably solve this > specific problem. > It would allow to build a big systemd based image and a minimal sysv > based rescue image out of one DISTRO. Right - this is also the solution you find in busybox's recipe. > > However, the solution would be very special. The user would have to add > swupdate and one of swupdate-systemd or swupdate-svinit packages to the > image. Yes, but user must already add specific swupdate packages, like swupdate-tools or swupdate-ww. I think it is not so bad. If we compare with QT with a big bunch of packages, it is not a lot.. > To simplify the default use case with one image, we could add something > like the following to the recipe: > > # Set this variable to an empty string in a bbappend, if you need > support for sysv and systemd image based systems with one common > swupdate build. > # This requires to explicitly add one of swupdate-sysv or > swupdate-systemd packages to IMAGE_INSTALL > SWUPDATE_ACTIVE_INIT ?= "${VIRTUAL-RUNTIME_init_manager}" > > RDEPENDS_${PN} += "swupdate-${SWUPDATE_ACTIVE_INIT}" > > > If we slightly adapt the current sysv script to source the new > /usr/lib/swupdate/swupdate.sh script instead of directly calling the > swupdate binary, the sysv case would become more generic and more equal > to the systemd case. Basically only the socket-file, the service-file > and the init script would be split out, but not the new shell script > snippets in /usr/lib/swupdate. > > What do you think? Should I send a v5 based on this idea? Splitting in packages was also my intention. I propose: - you send a stand-alone patch for the renaming of tools (swupdate-client, and so on.). I will integrate this very soon because building from TOT is currently broken. - send a V5 related to what you proposed for review. I will answer to your previous e-mail, too. Regards, Stefano
Hi Adrian, On 03/11/19 15:53, adrian.freihofer@gmail.com wrote: > Hi Stefano, hi Stefan > > There are, in my opinion, two points which should be reconsidered. > > 1) Is kbuild the right build-system for swupdate? > Who knows.. > The kbuild system is fine e.g. for the kernel or for uboot, but not > ideal for a user-space application such as swupdate. Well, I think nobody wants to start a big discussion about replacing build-system in kernel. Anyway, I think that the chosen build-system has not a lot to do if the target is kernel, bootloader or user space (application or library). Remembering U-Boot history, U-Boot had no build system at all. Configuration was done (and switch to Kbuild is not yet completed) with header files. This seemed simple at the early beginning, but it is bad to factorize and mistakes are very simple. I guess there is still a lot of "dead" code and defines in U-Boot. When the build system was discuss on U-Boot's ML, the logical conclusion was to take Kbuild because kernel has it. U-Boot takes a lot of things (drivers, and so on) from kernel. But this does not mean that U-Boot could not built using cmake, for example. In case of SWUpdate, I decided for Kbuild looking at busybox. As busybox is the Swiss knife for Unix tools, SWUpdate can be a SWiss knife for an updater. And because SWUpdate belongs to the low-level tools, a build system near to the kernel seemed a good compromize. Could be done with cmake ? Of course, yes. I am not so fixed to say that nothing can be changed. But please taken into account that this requires time, and surely this cannot happen before 2019.11 release. > With the kbuild system I do not know the "right" answers to the > questions we are currently discussing about. Compromises are required to > proceed here. > > Let's assume, there would be a cmake implementation providing a -D > parameter for each CONFIG_ option provided by the current kbuild based > implementation. > For Yocto, for each -D parameter, the corresponding PACKAGECONFIG option > needs to be provided.The default config could be defined like: > > PACKAGECONFIG ?= "${SWUPDATE_PACKAGECONFIG_MACHINE}". > With cmake a packageconfig, the way is quite clear. There are lot of examples. > This would probably (I've not seen something similar so far) allow to > define the MACHINE specific parameters (e.g. CONFIG_UBOOT, CONFIG_MTD) > in the machine.conf files. > > SWUPDATE_PACKAGECONFIG_MACHINE = "uboot mtd". Not sure here. > > Distro specific flags (e.g. CONFIG_SURICATTA_HAWKBIT) could be enabled > and disabled in the distro.conf file. No. This is project specific or image specific. It can be that an image is defined to use Hawkbit, another image just the Webserver or local update. > > PACKAGECONFIG_append_pn-swupdate = " suricatta-hawkbit" > > This example is very Yocto specific. But the logic behind applies to > other distros and build systems as well. If we change this, we should be sure to support again other buildsystems. I do not see issues with Debian-packaging, but Buildroot must be supported again. > > > 2) The init system is image specific > > I absolutely disagree. > > The Init Manager is a variable defined at the DISTRO level, not at the > image level. Changing the init system has a potential impact on the > build steps of each package. These build steps are executed before the > image is assembled. They should therefore be the same for all images > that can be created with one DISTRO. > > If a project requires two images, for example one with systemd and one > with busybox init, two DISTROs are required. Two DISTROs practically > mean two separate build folders. Only the sstate cache can be shared. > With recent Yocto versions "multiconfig" was introduced. As far as I > understand, it addresses exactly the use case we are discussing here. Well, I cannot replicate as my example in previous e-mail uses two DISTROs (mydistro with systemd and poky with SystemV). > > This is probably also the reason why poky does not split packages for > sysv scripts and systemd service files. Splitting packages would solve > just one problem among many to make the init system an image-level > configuration. > > > > This also means that v4 of my patch is based on a misunderstanding, v3 > was better. I propose to merge v3 of: > - "swupdate: improve systemd config" > - "swupdate: simplify find images added to swu" > > Please let us proceed with a pragmatic implementation and solve the more > fundamental problems later (e.g. kbuild or cmake or meson). As I said: I do not stick with the build system, but it should be done after release. The main question is what we win or we lose. I do not currently see many issues with Kbuild, just that the integration could be simplified. IMHO it is important that SWUpdate can adapt itself to any project (this is nowadays), and not that projects must adapt themselves to SWUpdate because SWUpdate (or build in meta-swupdate) does not allow some setup. At the moment, it is very flexible even if it is maybe not intuitive. > Please let us stop the discussion about fixing my patches to support > different init systems on image level. This is not how Yocto is supposed > to work. > Please let us focus on the best compromise to deal with kbuild. The > "perfect solution" is probably not possible with kbuild. > Best regards, Stefano > Thank you for your valuable feedback. > Best regards, > Adrian > > > > Am Sonntag, 3. November 2019 11:41:15 UTC+1 schrieb Stefano Babic: > > Hi Stefan, Adrian, > > On 03/11/19 09:48, Stefan Herbrechtsmeier wrote: > > Hi Adrian and Stefano, > > > > Am 02.11.19 um 22:48 schrieb adrian....@gmail.com <javascript:>: > >> Hi Stefano > >> > >> Am Samstag, 2. November 2019 14:39:48 UTC+1 schrieb Stefano Babic: > >> > >> On 29/10/19 11:01, Adrian Freihofer wrote: > > > > [snip] > > > >> > diff --git a/recipes-support/swupdate/swupdate.inc > >> b/recipes-support/swupdate/swupdate.inc > >> > index 392af31..1e4f92e 100644 > >> > --- a/recipes-support/swupdate/swupdate.inc > >> > +++ b/recipes-support/swupdate/swupdate.inc > >> > @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd > pkgconfig > >> > SRC_URI = > "git://github.com/sbabic/swupdate.git;protocol=https > <http://github.com/sbabic/swupdate.git;protocol=https> > >> <http://github.com/sbabic/swupdate.git;protocol=https > <http://github.com/sbabic/swupdate.git;protocol=https>> \ > >> > file://defconfig \ > >> > file://swupdate \ > >> > - file://swupdate.service \ > >> > - file://swupdate-usb.rules \ > >> > - file://swupdate-usb@.service \ > >> > - file://swupdate-progress.service \ > >> > - file://systemd-tmpfiles-swupdate.conf \ > >> > " > >> > > >> > +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools" > >> > INSANE_SKIP_${PN} = "ldflags" > >> > -PACKAGES =+ "${PN}-www ${PN}-lua" > >> > +INSANE_SKIP_${PN}-tools = "ldflags" > >> > > >> > FILES_${PN}-lua += "${libdir}/lua/" > >> > -FILES_${PN}-www = "/www/*" > >> > -FILES_${PN} += "${libdir}/tmpfiles.d" > >> > +FILES_${PN}-www = " \ > >> > + ${libdir}/swupdate/conf.d/*mongoose* \ > >> > + /www/* \ > >> > +" > >> > +FILES_${PN}-tools = " \ > >> > + ${bindir}/swupdate-client \ > >> > + ${bindir}/swupdate-progress \ > >> > + ${systemd_system_unitdir}/swupdate-progress.service \ > >> > + ${bindir}/swupdate-hawkbitcfg \ > >> > + ${bindir}/swupdate-sendtohawkbit \ > >> > +" > >> > +FILES_${PN} += " \ > >> > + ${libdir}/tmpfiles.d \ > >> > + ${libdir}/swupdate/* \ > >> > + ${systemd_system_unitdir}/swupdate.socket \ > >> > + ${systemd_system_unitdir}/swupdate.service \ > >> > + ${systemd_system_unitdir}/swupdate-usb@.service \ > >> > +" > >> > > >> > S = "${WORKDIR}/git/" > >> > > >> > @@ -116,17 +128,21 @@ python () { > >> > } > >> > > >> > do_configure () { > >> > - cp ${WORKDIR}/defconfig ${S}/.config > >> > - merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > >> > - cml1_do_configure > >> > + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', > >> 'true', 'false', d)}; then > >> > >> I think this is not correct. Even if systemd is listed in the > >> features > >> for DISTRO, a user can select SystemV as init manager. The check > >> should > >> be based on VIRTUAL-RUNTIME_init_manager instead of DISTRO. > >> > >> Will be changed with v4, thanks. > > > > NACK. The init manager could be image specific. > > You are right - this is also a common pattern. > > > It is a common pattern > > do enable systemd support via DISTRO feature. > > Enable is one point, if systemd is active is another point, and a > package cannot know (and should be unaware) which init manager will > run. > It should provide support for both. > > > We could use a variable > > like PACKAGECONFIG or a option like CONFIG_SYSTEMD in the > defconfig to > > give the user the possibility to control it. > > But then we want to add dependencies between SWUpdate as project itself > and the environment (with or without systemd) where it will run. > SWUpdate should be unaware of it. What about to install always systemd > related files but put them in a sparate package (swupdate-systemd) ? > > > The later leads to the > > problem that a distro feature (systemd) is controlled by machine > > specific file. > > Not always. > > What about if systemd is in DISTRO_FEATURES for my own distro (in my > layer), but I need to build an image for another distro, for example: > > DISTRO=mydistro bitbake my-imgae > DISTRO=poky bitbake my-imgae > > Poky uses as default SystemV, my-distro (set in one of configuration > file) sets systemd. The above example is not built, it makes sense with > SWUpdate in case of rescue image because systemd adds a significant > overload. > > > > >> > + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > > >> ${S}/.config > >> > + echo "# Global settings from swupdate recipe" >> > >> ${S}/.config > >> > + echo "CONFIG_SYSTEMD=y" >> ${S}/.config > >> > + echo > >> "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> > >> ${S}/.config > >> > >> I understand the logic, but I have an understanding problem. > In fact, > >> who is the master ? > > > > Usually the recipe is the master in OE but this is only partially > true > > for kconfig recipes. > > I would say it is not true - see kernel class and build for busybox. > IMHO in these cases the defconfig is the master. > > > > >> > >> > >> In current implementation, defconfig is the master. > > > > This is the problem because the defconfig couldn't depend on the > distro > > and machine together. Furthermore it couldn't be influence by OE > variables. > > > >> If a user run > >> "bitbake -c menuconfig swupdate" or add fragments to the > >> configuration, > >> this becomes the master. In fact, the current recipes do not > try to > >> change defconfig, but set OE to reflect the values in defconfig. > >> This is > >> the reason for the anonymous python function in swupdate.inc. > This > >> adds > >> DEPENDS to the list, quite an exception in OE. Because the > list of > >> depends can be short or long, on depends of the configuration. > > > > What was the reason to use this exception instead of a list of > > PACKAGECONFIGs and a generated configuration? > > As far as I know this does not work together with defconfig and > fragments. Using fragments is supported in meta-swupdate, as well as > "bitbake -c menuconfig swupdate". If there is a solution to not break > these workflow, we can take it. > > Please consider that OE is not the only buildsystem supported, even > if a > lot of changes are thought for OE and I confess I use OE for most of my > projects (but not all..). Buildroot and debian are supported and > must be > supported in future, too. > > > > > >> However, the single case above seems "quite" ok to me. > CONFIG_SYSTEMD > >> comes from defconfig. But should not be responsibility of the > user to > >> set CONFIG_SYSTEMD_SYSTEM_UNITDIR instead of forcing it ? > > > > This option is managed by OE / distro and shouldn't be set via the > user. > > Especially not via a machine specific and distro independent file. > > Shouldn't does not mean forbidden or that there are not cases where it > makes sense. IMHO we have to split between CONFIG_ that are part of > SWUPdate's configuration because internal behavior of SWUpdate changes > (like CONFIG_SYSTEMD because notifications are sent), and CONFIG_ that > define environmnet where SWUpdate will run, like > CONFIG_SYSTEMD_SYSTEM_UNITDIR, because no changes in code is requested: > this just install units into the system. > > > > >> I have the same question. That's the reason why I initially came up > >> with a different implementation. > >> At least with Yocto, it does not make sense to ask the user about > the > >> systemd_system_unitdir variable which is in fact not configurable. > > > > This is a generic problem of distro specific configurations and meta > > build systems. How should the configuration tool knows that some > > configurations are managed by the meta build system? > > Right. > > > > >> The build system knows the variable. In this case, menuconfig just > >> enables the user to break the build, without providing any > flexibility. > > > > We could use "sed" to replace the value in the .config or we could > use a > > cfg file to make the problem visible to the user. > > > >> I would still prefer to pass systemd_system_unitdir directly to the > >> make install target as an environment variable. > > > > What would be next? We pass the LUAPKG directly to make and all > system > > directories to make install? > > > > Please don't break common and widely-used rules because it is > simple to > > do so. > > Not searching for easy solution, but also I do not want to break > current > workflow. > > > > >> However, I see the argument about passing variables to the configure > >> step instead of passing a variable to the install step. > >> But passing variables to the configure step seems not really > supported > >> by the kbuild build system. > > > > This is the real problem > > Exactly. > > > and maybe the reason why OE create the > > configuration on the fly from the recipe for all other build tools > > (autotools, cmake, meson).> > > Do we really need the menuconfig or could this be handled by a > list of > > PACKAGECONFIGs? > > See above. There were already a patch for PACKAGECONFIG, but it breaks > using menuconfig and fragments. > > > > > Maybe it is possible to hide some options in menuconfig when it is > > started by OE. > > Mhhh...good idea. Ye, this is possible, too. > > > > >> Patching the config file is probably the only way to define the > >> variable during the configure step. > > > > Other recipes do the same. > > > >> I think the current implementation is not wrong and it could be > >> merged. But we could also go back to the line of code in my first > >> patch version. > > > > NACK > > > >> > >> > >> > + else > >> > + cp ${WORKDIR}/defconfig ${S}/.config > >> > + fi > >> > + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} > >> > + cml1_do_configure > >> > } > >> > > >> > do_compile() { > >> > unset LDFLAGS > >> > - oe_runmake swupdate_unstripped progress_unstripped > >> > - cp swupdate_unstripped swupdate > >> > - cp progress_unstripped progress > >> > - > >> > + oe_runmake > >> > } > >> > > >> > do_install () { > >> > @@ -142,23 +158,15 @@ do_install () { > >> > > >> > install -d ${D}${sysconfdir}/init.d > >> > install -m 755 ${WORKDIR}/swupdate > ${D}${sysconfdir}/init.d > >> > - > >> > - install -d ${D}${systemd_unitdir}/system > >> > - install -m 644 ${WORKDIR}/swupdate.service > >> ${D}${systemd_unitdir}/system > >> > - install -m 644 ${WORKDIR}/swupdate-usb@.service > >> ${D}${systemd_unitdir}/system > >> > - install -m 644 ${WORKDIR}/swupdate-progress.service > >> ${D}${systemd_unitdir}/system > >> > - > >> > - > >> > - if > >> > ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; > >> then > >> > - install -d ${D}${libdir}/tmpfiles.d > >> > - install -m 0644 > ${WORKDIR}/systemd-tmpfiles-swupdate.conf > >> ${D}${libdir}/tmpfiles.d/swupdate.conf > >> > - install -d ${D}${sysconfdir}/udev/rules.d > >> > - install -m 0644 ${WORKDIR}/swupdate-usb.rules > >> ${D}${sysconfdir}/udev/rules.d/ > >> > - fi > >> > } > >> > > >> > INITSCRIPT_NAME = "swupdate" > >> > INITSCRIPT_PARAMS = "defaults 70" > >> > > >> > -SYSTEMD_SERVICE_${PN} = "swupdate.service" > >> > -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service > >> swupdate-progress.service" > >> > >> A question that was raised more as one time on this list is > if we > >> have > >> to split services into different packages. Not only > >> swupdate-progress, > >> but what about if a USB update is forbidden on the target ? A > project > >> should be able to decide which services should be installed and > >> which not. > >> > >> Shortly tried to implement that on top of this MR. It's easy, but > not > >> backward compatible. > >> Therefore, I would like to discuss this in another MR. Probably not > >> many users are following these details here any more. > > > > ACK > > Ok, let's proceed in this way. > > Best regards, > Stefano > > -- > ===================================================================== > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: > sba...@denx.de <javascript:> > ===================================================================== > > -- > You received this message because you are subscribed to the Google > Groups "swupdate" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to swupdate+unsubscribe@googlegroups.com > <mailto:swupdate+unsubscribe@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/swupdate/bb994447-4b2e-49fd-ba30-c3ee7e07f8a2%40googlegroups.com > <https://groups.google.com/d/msgid/swupdate/bb994447-4b2e-49fd-ba30-c3ee7e07f8a2%40googlegroups.com?utm_medium=email&utm_source=footer>.
diff --git a/recipes-support/swupdate/swupdate/swupdate-progress.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service similarity index 100% rename from recipes-support/swupdate/swupdate/swupdate-progress.service rename to recipes-support/swupdate/swupdate-2019.04/swupdate-progress.service diff --git a/recipes-support/swupdate/swupdate/swupdate-usb.rules b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules similarity index 100% rename from recipes-support/swupdate/swupdate/swupdate-usb.rules rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb.rules diff --git a/recipes-support/swupdate/swupdate/swupdate-usb@.service b/recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service similarity index 100% rename from recipes-support/swupdate/swupdate/swupdate-usb@.service rename to recipes-support/swupdate/swupdate-2019.04/swupdate-usb@.service diff --git a/recipes-support/swupdate/swupdate/swupdate.service b/recipes-support/swupdate/swupdate-2019.04/swupdate.service similarity index 100% rename from recipes-support/swupdate/swupdate/swupdate.service rename to recipes-support/swupdate/swupdate-2019.04/swupdate.service diff --git a/recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf b/recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf similarity index 100% rename from recipes-support/swupdate/swupdate/systemd-tmpfiles-swupdate.conf rename to recipes-support/swupdate/swupdate-2019.04/systemd-tmpfiles-swupdate.conf diff --git a/recipes-support/swupdate/swupdate.inc b/recipes-support/swupdate/swupdate.inc index 392af31..1e4f92e 100644 --- a/recipes-support/swupdate/swupdate.inc +++ b/recipes-support/swupdate/swupdate.inc @@ -10,19 +10,31 @@ inherit cml1 update-rc.d systemd pkgconfig SRC_URI = "git://github.com/sbabic/swupdate.git;protocol=https \ file://defconfig \ file://swupdate \ - file://swupdate.service \ - file://swupdate-usb.rules \ - file://swupdate-usb@.service \ - file://swupdate-progress.service \ - file://systemd-tmpfiles-swupdate.conf \ " +PACKAGES =+ "${PN}-www ${PN}-lua ${PN}-tools" INSANE_SKIP_${PN} = "ldflags" -PACKAGES =+ "${PN}-www ${PN}-lua" +INSANE_SKIP_${PN}-tools = "ldflags" FILES_${PN}-lua += "${libdir}/lua/" -FILES_${PN}-www = "/www/*" -FILES_${PN} += "${libdir}/tmpfiles.d" +FILES_${PN}-www = " \ + ${libdir}/swupdate/conf.d/*mongoose* \ + /www/* \ +" +FILES_${PN}-tools = " \ + ${bindir}/swupdate-client \ + ${bindir}/swupdate-progress \ + ${systemd_system_unitdir}/swupdate-progress.service \ + ${bindir}/swupdate-hawkbitcfg \ + ${bindir}/swupdate-sendtohawkbit \ +" +FILES_${PN} += " \ + ${libdir}/tmpfiles.d \ + ${libdir}/swupdate/* \ + ${systemd_system_unitdir}/swupdate.socket \ + ${systemd_system_unitdir}/swupdate.service \ + ${systemd_system_unitdir}/swupdate-usb@.service \ +" S = "${WORKDIR}/git/" @@ -116,17 +128,21 @@ python () { } do_configure () { - cp ${WORKDIR}/defconfig ${S}/.config - merge_config.sh -m .config ${@" ".join(find_cfgs(d))} - cml1_do_configure + if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then + grep -v 'CONFIG_SYSTEMD' ${WORKDIR}/defconfig > ${S}/.config + echo "# Global settings from swupdate recipe" >> ${S}/.config + echo "CONFIG_SYSTEMD=y" >> ${S}/.config + echo "CONFIG_SYSTEMD_SYSTEM_UNITDIR=\"${systemd_system_unitdir}\"" >> ${S}/.config + else + cp ${WORKDIR}/defconfig ${S}/.config + fi + merge_config.sh -m .config ${@" ".join(find_cfgs(d))} + cml1_do_configure } do_compile() { unset LDFLAGS - oe_runmake swupdate_unstripped progress_unstripped - cp swupdate_unstripped swupdate - cp progress_unstripped progress - + oe_runmake } do_install () { @@ -142,23 +158,15 @@ do_install () { install -d ${D}${sysconfdir}/init.d install -m 755 ${WORKDIR}/swupdate ${D}${sysconfdir}/init.d - - install -d ${D}${systemd_unitdir}/system - install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_unitdir}/system - install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_unitdir}/system - install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_unitdir}/system - - - if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then - install -d ${D}${libdir}/tmpfiles.d - install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf - install -d ${D}${sysconfdir}/udev/rules.d - install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/ - fi } INITSCRIPT_NAME = "swupdate" INITSCRIPT_PARAMS = "defaults 70" -SYSTEMD_SERVICE_${PN} = "swupdate.service" -SYSTEMD_SERVICE_${PN} += "swupdate-usb@.service swupdate-progress.service" +SYSTEMD_SERVICE_${PN} = " \ + swupdate.service \ + swupdate-usb@.service \ + " + +SYSTEMD_PACKAGES_append = " ${PN}-tools" +SYSTEMD_SERVICE_${PN}-tools = "swupdate-progress.service" diff --git a/recipes-support/swupdate/swupdate_2019.04.bb b/recipes-support/swupdate/swupdate_2019.04.bb index e2eabbb..5b0fb78 100644 --- a/recipes-support/swupdate/swupdate_2019.04.bb +++ b/recipes-support/swupdate/swupdate_2019.04.bb @@ -1,4 +1,30 @@ require swupdate.inc -require swupdate_tools.inc + +SRC_URI += " \ + file://swupdate.service \ + file://swupdate-usb.rules \ + file://swupdate-usb@.service \ + file://swupdate-progress.service \ + file://systemd-tmpfiles-swupdate.conf \ + " SRCREV = "d39f4b8e00ef1929545b66158e45b82ea922bf81" + +do_install_append () { + # Rename the binaries installed by make install + test -f ${D}${bindir}/progress && mv ${D}${bindir}/progress ${D}${bindir}/swupdate-progress + test -f ${D}${bindir}/client && mv ${D}${bindir}/client ${D}${bindir}/swupdate-client + test -f ${D}${bindir}/hawkbitcfg && mv ${D}${bindir}/hawkbitcfg ${D}${bindir}/swupdate-hawkbitcfg + test -f ${D}${bindir}/sendtohawkbit && mv ${D}${bindir}/sendtohawkbit ${D}${bindir}/swupdate-sendtohawkbit + + install -d ${D}${systemd_system_unitdir} + install -m 644 ${WORKDIR}/swupdate.service ${D}${systemd_system_unitdir} + install -m 644 ${WORKDIR}/swupdate-usb@.service ${D}${systemd_system_unitdir} + install -m 644 ${WORKDIR}/swupdate-progress.service ${D}${systemd_system_unitdir} + if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)}; then + install -d ${D}${libdir}/tmpfiles.d + install -m 0644 ${WORKDIR}/systemd-tmpfiles-swupdate.conf ${D}${libdir}/tmpfiles.d/swupdate.conf + install -d ${D}${sysconfdir}/udev/rules.d + install -m 0644 ${WORKDIR}/swupdate-usb.rules ${D}${sysconfdir}/udev/rules.d/ + fi +} diff --git a/recipes-support/swupdate/swupdate_git.bb b/recipes-support/swupdate/swupdate_git.bb index 9fea83a..8eef04e 100644 --- a/recipes-support/swupdate/swupdate_git.bb +++ b/recipes-support/swupdate/swupdate_git.bb @@ -1,7 +1,10 @@ require swupdate.inc -require swupdate_tools.inc DEFAULT_PREFERENCE = "-1" SRCREV ?= "045a618a725d0a2fce64161f10101c0004ac5d85" PV = "2019.04+git${SRCPV}" + +SYSTEMD_SERVICE_${PN} += " \ + swupdate.socket \ +" diff --git a/recipes-support/swupdate/swupdate_tools.inc b/recipes-support/swupdate/swupdate_tools.inc deleted file mode 100644 index d270dd4..0000000 --- a/recipes-support/swupdate/swupdate_tools.inc +++ /dev/null @@ -1,24 +0,0 @@ -PACKAGES =+ "${PN}-tools" - -INSANE_SKIP_${PN}-tools = "ldflags" - -FILES_${PN}-tools = "${bindir}/swupdate-client \ - ${bindir}/swupdate-progress \ - ${bindir}/swupdate-hawkbitcfg \ - ${bindir}/swupdate-sendtohawkbit" - -do_compile() { - unset LDFLAGS - - oe_runmake - cp swupdate_unstripped swupdate -} - -do_install_append () { - - install -m 0755 tools/client_unstripped ${D}${bindir}/swupdate-client - install -m 0755 tools/progress_unstripped ${D}${bindir}/swupdate-progress - install -m 0755 tools/hawkbitcfg_unstripped ${D}${bindir}/swupdate-hawkbitcfg - install -m 0755 tools/sendtohawkbit_unstripped ${D}${bindir}/swupdate-sendtohawkbit - -}
For most projects starting swupdate requires some logic implemented in shell scripts. Therefore swupdate is now started by a shell script also in case of systemd is anabled in DISTRO_FEATURES. The new swupdate startup script sources code snippets located in /usr/lib/swupdate/conf.d and in /etc/swupdate/conf.d. The snippets are executed in alphabetical order. The idea is that files in /usr are added at build time and files in /etc might be added or modified at run-time. If two scripts, one in /etc and one in /usr have the same file name, the script in /usr gets skipped completely. This allows to disable code in /usr, which is probably mounted ro, at runtime. Code snippets are automatically generated at build-time, depending on the configuration created by swupdate's menuconfig. But code snippets may be created manually and added via bbappend to the /usr/lib/swupdate/conf.d folder. All modes (file, webserver, webclient) of swupdate are supported. Different variables might be defined by the code snippets added to the named folders: - SWUPDATE_ARGS - SWUPDATE_WEBSERVER_ARGS - SWUPDATE_DOWNLOAD_ARGS Finally swupdate gets started by a line similar to: exec /usr/bin/swupdate $SWUPDATE_ARGS \ -w "$SWUPDATE_WEBSERVER_ARGS" \ -u "$SWUPDATE_DOWNLOAD_ARGS" The default set of configuraton and service files is now installed by the "make install" target of the swupdate Makefile. The service files which are not used for the latest git version of swupdate are moved to swupdate-2019.04 folder. fixes in do_install This changes the filenames of the tools binaries for several reasons: - Binaries should not be named "client" or "progress" (also not accepted by Debian upstream) - Inconsistent with names referred in the service files The swupdate_tools.inc file gets merged into swupdate.inc file. By removing the tools file some bugs are fixed: - The tools binaries were installed twice. - do_compile from swupdate.inc was over written resulting in wired behavior - swupdate-progress.service file was part of swupdate package were the corresponding swupdate-progress binary was part of the tools package. The tools are now installed by the "make install" target of swupdate's Makefile. The related code here in meta-swupdate gets removed. Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> --- .../swupdate-progress.service | 0 .../swupdate-usb.rules | 0 .../swupdate-usb@.service | 0 .../swupdate.service | 0 .../systemd-tmpfiles-swupdate.conf | 0 recipes-support/swupdate/swupdate.inc | 68 ++++++++++++---------- recipes-support/swupdate/swupdate_2019.04.bb | 28 ++++++++- recipes-support/swupdate/swupdate_git.bb | 5 +- recipes-support/swupdate/swupdate_tools.inc | 24 -------- 9 files changed, 69 insertions(+), 56 deletions(-) rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-progress.service (100%) rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb.rules (100%) rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate-usb@.service (100%) rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/swupdate.service (100%) rename recipes-support/swupdate/{swupdate => swupdate-2019.04}/systemd-tmpfiles-swupdate.conf (100%) delete mode 100644 recipes-support/swupdate/swupdate_tools.inc