[v3,1/3] swupdate: improve systemd config
diff mbox series

Message ID 20191029100113.27287-2-adrian.freihofer@siemens.com
State Changes Requested
Headers show
Series
  • simplify swupdate config
Related show

Commit Message

Freihofer, Adrian Oct. 29, 2019, 10:01 a.m. UTC
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

Comments

Stefano Babic Nov. 2, 2019, 1:39 p.m. UTC | #1
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
Adrian Freihofer Nov. 2, 2019, 9:48 p.m. UTC | #2
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:> 
> ===================================================================== 
>
Stefan Herbrechtsmeier Nov. 3, 2019, 8:48 a.m. UTC | #3
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
Stefano Babic Nov. 3, 2019, 10:40 a.m. UTC | #4
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
Adrian Freihofer Nov. 3, 2019, 2:53 p.m. UTC | #5
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:> 
> ===================================================================== 
>
Adrian Freihofer Nov. 3, 2019, 5:22 p.m. UTC | #6
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
Stefano Babic Nov. 3, 2019, 7:04 p.m. UTC | #7
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
Stefano Babic Nov. 3, 2019, 7:29 p.m. UTC | #8
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>.

Patch
diff mbox series

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
-
-}