Message ID | 20200710222656.6885-1-nolange79@gmail.com |
---|---|
State | Changes Requested |
Headers | show |
Series | [v2] package/systemd: use current tool for generating HWDB | expand |
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 <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. | > > '------------------------------^-------^------------------^--------------------' >
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 <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
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 \
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(-)