[Buildroot] [PATCH v2] package/systemd: use current tool for generating HWDB

[Buildroot] [PATCH v2] package/systemd: use current tool for generating HWDB

[Norbert Lange]

udevadm has been deprecated for a while(for bulding the DB),
systemd-hwdb should be used in its place.

this tool further has a switch to generate the database in
/usr which is a better place for a one-time created file.

Also remove the config files from both paths
(rootfs overlay could add stuff) aswell as the service and tool
from the target fs.

Signed-off-by: Norbert Lange <nolange79@gmail.com>

---
v1 -> v2
-   fix removal of service
---
 package/systemd/systemd.mk | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
index 1a8eb86e53..05c1d1ff9a 100644
--- a/package/systemd/systemd.mk
+++ b/package/systemd/systemd.mk
@@ -229,11 +229,14 @@ endif
 ifeq ($(BR2_PACKAGE_SYSTEMD_HWDB),y)
 SYSTEMD_CONF_OPTS += -Dhwdb=true
 define SYSTEMD_BUILD_HWDB
-	$(HOST_DIR)/bin/udevadm hwdb --update --root $(TARGET_DIR)
+	$(HOST_DIR)/bin/systemd-hwdb update --root $(TARGET_DIR) --usr
 endef
 SYSTEMD_TARGET_FINALIZE_HOOKS += SYSTEMD_BUILD_HWDB
 define SYSTEMD_RM_HWDB_SRV
-	rm -rf $(TARGET_DIR)/$(HOST_EUDEV_SYSCONFDIR)/udev/hwdb.d/
+	rm -rf $(TARGET_DIR)/usr/lib/udev/hwdb.d/ $(TARGET_DIR)/etc/udev/hwdb.d/ \
+		$(TARGET_DIR)/usr/lib/systemd/system/systemd-hwdb-update.service \
+		$(TARGET_DIR)/usr/lib/systemd/system/*/systemd-hwdb-update.service \
+		$(TARGET_DIR)/usr/bin/systemd-hwdb
 endef
 SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_SRV
 else
@@ -633,7 +636,7 @@ HOST_SYSTEMD_CONF_OPTS = \
 	-Dsysusers=false \
 	-Dtmpfiles=false \
 	-Dimportd=false \
-	-Dhwdb=false \
+	-Dhwdb=true \
 	-Drfkill=false \
 	-Dman=false \
 	-Dhtml=false \
-- 
2.27.0

[Buildroot] [PATCH v2] package/systemd: use current tool for generating HWDB

[Yann E. MORIN]

Norbert, All,

On 2020-07-11 00:26 +0200, Norbert Lange spake thusly:
> udevadm has been deprecated for a while(for bulding the DB),
> systemd-hwdb should be used in its place.
> 
> this tool further has a switch to generate the database in
> /usr which is a better place for a one-time created file.

... rather than the default /etc/udev.

> Also remove the config files from both paths
> (rootfs overlay could add stuff) aswell as the service and tool
> from the target fs.

This 'also' hints at the need to split the patch in two: one to switch
to using systemd-hwdb, and one to remove the service.

However, I'm against removing the service altogether, because in the
past, some people have expressed the need to be able to update the hwdb
on-target.

I would be OK with having a drop-in that disables the service by default
when BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set, though.

> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> 
> ---
> v1 -> v2
> -   fix removal of service
> ---
>  package/systemd/systemd.mk | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> index 1a8eb86e53..05c1d1ff9a 100644
> --- a/package/systemd/systemd.mk
> +++ b/package/systemd/systemd.mk
> @@ -229,11 +229,14 @@ endif
>  ifeq ($(BR2_PACKAGE_SYSTEMD_HWDB),y)
>  SYSTEMD_CONF_OPTS += -Dhwdb=true
>  define SYSTEMD_BUILD_HWDB
> -	$(HOST_DIR)/bin/udevadm hwdb --update --root $(TARGET_DIR)
> +	$(HOST_DIR)/bin/systemd-hwdb update --root $(TARGET_DIR) --usr

Don;t we want to use --strict too?

Regards,
Yann E. MORIN.

>  endef
>  SYSTEMD_TARGET_FINALIZE_HOOKS += SYSTEMD_BUILD_HWDB
>  define SYSTEMD_RM_HWDB_SRV
> -	rm -rf $(TARGET_DIR)/$(HOST_EUDEV_SYSCONFDIR)/udev/hwdb.d/
> +	rm -rf $(TARGET_DIR)/usr/lib/udev/hwdb.d/ $(TARGET_DIR)/etc/udev/hwdb.d/ \
> +		$(TARGET_DIR)/usr/lib/systemd/system/systemd-hwdb-update.service \
> +		$(TARGET_DIR)/usr/lib/systemd/system/*/systemd-hwdb-update.service \
> +		$(TARGET_DIR)/usr/bin/systemd-hwdb
>  endef
>  SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_SRV
>  else
> @@ -633,7 +636,7 @@ HOST_SYSTEMD_CONF_OPTS = \
>  	-Dsysusers=false \
>  	-Dtmpfiles=false \
>  	-Dimportd=false \
> -	-Dhwdb=false \
> +	-Dhwdb=true \
>  	-Drfkill=false \
>  	-Dman=false \
>  	-Dhtml=false \
> -- 
> 2.27.0
> 

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2] package/systemd: use current tool for generating HWDB

[Norbert Lange]

Yann E. MORIN <yann.morin.1998@free.fr> schrieb am Sa., 11. Juli 2020,
13:27:

> Norbert, All,
>
> On 2020-07-11 00:26 +0200, Norbert Lange spake thusly:
> > udevadm has been deprecated for a while(for bulding the DB),
> > systemd-hwdb should be used in its place.
> >
> > this tool further has a switch to generate the database in
> > /usr which is a better place for a one-time created file.
>
> ... rather than the default /etc/udev.
>
> > Also remove the config files from both paths
> > (rootfs overlay could add stuff) aswell as the service and tool
> > from the target fs.
>
> This 'also' hints at the need to split the patch in two: one to switch
> to using systemd-hwdb, and one to remove the service.
>

Ok.

>
> However, I'm against removing the service altogether, because in the
> past, some people have expressed the need to be able to update the hwdb
> on-target.
>

That would be challenging, as the source files for the database were
already removed before this patch.

If they had to re-add those, then a adding a tool and service from the
target directory won't be too much to ask?

I mean buildroot pretty much doesn't support some sorta packet manager
system by design.
Why the exception here?


> I would be OK with having a drop-in that disables the service by default
> when BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set, though.
>

It will only run when /usr is newer than /etc AFAIR (not sure how this is
determined), so disabling does very little.

BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW already has too many
surprising effects for me.


> > Signed-off-by: Norbert Lange <nolange79@gmail.com>
> >
> > ---
> > v1 -> v2
> > -   fix removal of service
> > ---
> >  package/systemd/systemd.mk | 9 ++++++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/package/systemd/systemd.mk b/package/systemd/systemd.mk
> > index 1a8eb86e53..05c1d1ff9a 100644
> > --- a/package/systemd/systemd.mk
> > +++ b/package/systemd/systemd.mk
> > @@ -229,11 +229,14 @@ endif
> >  ifeq ($(BR2_PACKAGE_SYSTEMD_HWDB),y)
> >  SYSTEMD_CONF_OPTS += -Dhwdb=true
> >  define SYSTEMD_BUILD_HWDB
> > -     $(HOST_DIR)/bin/udevadm hwdb --update --root $(TARGET_DIR)
> > +     $(HOST_DIR)/bin/systemd-hwdb update --root $(TARGET_DIR) --usr
>
> Don;t we want to use --strict too?
>

Ok.


> Regards,
> Yann E. MORIN.
>
> >  endef
> >  SYSTEMD_TARGET_FINALIZE_HOOKS += SYSTEMD_BUILD_HWDB
> >  define SYSTEMD_RM_HWDB_SRV
> > -     rm -rf $(TARGET_DIR)/$(HOST_EUDEV_SYSCONFDIR)/udev/hwdb.d/
> > +     rm -rf $(TARGET_DIR)/usr/lib/udev/hwdb.d/
> $(TARGET_DIR)/etc/udev/hwdb.d/ \
> > +
>  $(TARGET_DIR)/usr/lib/systemd/system/systemd-hwdb-update.service \
> > +
>  $(TARGET_DIR)/usr/lib/systemd/system/*/systemd-hwdb-update.service \
> > +             $(TARGET_DIR)/usr/bin/systemd-hwdb
> >  endef
> >  SYSTEMD_ROOTFS_PRE_CMD_HOOKS += SYSTEMD_RM_HWDB_SRV
> >  else
> > @@ -633,7 +636,7 @@ HOST_SYSTEMD_CONF_OPTS = \
> >       -Dsysusers=false \
> >       -Dtmpfiles=false \
> >       -Dimportd=false \
> > -     -Dhwdb=false \
> > +     -Dhwdb=true \
> >       -Drfkill=false \
> >       -Dman=false \
> >       -Dhtml=false \
> > --
> > 2.27.0
> >
>
> --
>
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics'
> conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___
>      |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is
> no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v
>  conspiracy.  |
>
> '------------------------------^-------^------------------^--------------------'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200711/0167f02b/attachment.html>

[Buildroot] [PATCH v2] package/systemd: use current tool for generating HWDB

[Yann E. MORIN]

Norbert, All,

On 2020-07-11 13:57 +0200, Norbert Lange spake thusly:
> Yann E. MORIN < [1]yann.morin.1998@free.fr> schrieb am Sa., 11. Juli 2020, 13:27:
>   On 2020-07-11 00:26 +0200, Norbert Lange spake thusly:
[--SNIP--]
>   > Also remove the config files from both paths
>   > (rootfs overlay could add stuff) aswell as the service and tool
>   > from the target fs.
[--SNIP--]
>   However, I'm against removing the service altogether, because in the
>   past, some people have expressed the need to be able to update the hwdb
>   on-target.
> 
> That would be challenging, as the source files for the database were already removed before this patch.
> If they had to re-add those, then a adding a tool and service from the target directory won't be too much to ask?

Those people would indeed be responsible for downloading the source
again, and re-run the update.

> I mean buildroot pretty much doesn't support some sorta packet manager system by design.
> Why the exception here?

I don;t remember, but IIRC there was a rather-copnvioning argument in
favour of it.

>   I would be OK with having a drop-in that disables the service by default
>   when BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set, though.
> 
> It will only run when /usr is newer than /etc AFAIR (not sure how this is determined),

See commit bbe5c6dad4d (Makefile: Update mtime of $(TARGET_DIR)/usr in
target-finalize) which goal was to adress this.

> so disabling does very little.
> BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW already has too many?
> surprising effects for me.

I too am not very happy with BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW,
because one can still select a squashfs filesystem at the same time.,
and that does not make sense to remount R/W a sqsh, as it is R/O by
nature.

But heck, I don't find it very logical that we can build more than one
filesystem at the same time either (we should have a choice there),
so...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH v2] package/systemd: use current tool for generating HWDB

[Norbert Lange]

Yann E. MORIN <yann.morin.1998@free.fr> schrieb am Sa., 11. Juli 2020,
14:12:

> Norbert, All,
>
> On 2020-07-11 13:57 +0200, Norbert Lange spake thusly:
> > Yann E. MORIN < [1]yann.morin.1998@free.fr> schrieb am Sa., 11. Juli
> 2020, 13:27:
> >   On 2020-07-11 00:26 +0200, Norbert Lange spake thusly:
> [--SNIP--]
> >   > Also remove the config files from both paths
> >   > (rootfs overlay could add stuff) aswell as the service and tool
> >   > from the target fs.
> [--SNIP--]
> >   However, I'm against removing the service altogether, because in the
> >   past, some people have expressed the need to be able to update the hwdb
> >   on-target.
> >
> > That would be challenging, as the source files for the database were
> already removed before this patch.
> > If they had to re-add those, then a adding a tool and service from the
> target directory won't be too much to ask?
>
> Those people would indeed be responsible for downloading the source
> again, and re-run the update.
>
> > I mean buildroot pretty much doesn't support some sorta packet manager
> system by design.
> > Why the exception here?
>
> I don;t remember, but IIRC there was a rather-copnvioning argument in
> favour of it.
>

Yeah, but I guess that's a very specialised need, and I don't get why they
don't just manually run systemd-hwdb after transferring the source files.
Or even do everything on the host and copy over the final DB.

Further, the service does something different (systemd-hwdb without --usr)
compared to both old (udevadm) and proposed new (--usr) buildroot hook.
And as the files are now not within /etc, and the service is primed on
that, this could end up in further oddities.


> >   I would be OK with having a drop-in that disables the service by
> default
> >   when BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is not set, though.
> >
> > It will only run when /usr is newer than /etc AFAIR (not sure how this
> is determined),
>
> See commit bbe5c6dad4d (Makefile: Update mtime of $(TARGET_DIR)/usr in
> target-finalize) which goal was to adress this.


> > so disabling does very little.
> > BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW already has too many
> > surprising effects for me.
>
> I too am not very happy with BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW,
> because one can still select a squashfs filesystem at the same time.,
> and that does not make sense to remount R/W a sqsh, as it is R/O by
> nature.


Or pack /usr into separate filesystem, or use an overlay (which is my
pick). I'd be happy if there's some file at the end with paths that can be
removed if the distribution is "write once".

Could just remove those paths in a fake root script, or after a one-time
setup on the target.

But heck, I don't find it very logical that we can build more than one
> filesystem at the same time either (we should have a choice there),
> so...
>

Some more "meta" like a list of files to remove or copy could help in
various post-processing.

Norbert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20200711/37242ef8/attachment.html>