Re: lvm2-udeb: uninstallable, depends on non-udeb libsystemd0
Control: tags -1 + patch
Control: user devel@kali.org
Control: usertags -1 + kali-patch
On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois <kibi@debian.org> wrote:
> I suppose the journal bits could be patched out for the udeb build (right
> now, configure ends up defining SYSTEMD_JOURNAL_SUPPORT to 1 there), but
> I'm not sure what consequences disabling APP_MACHINEID_SUPPORT in the udeb
> could have for arrays built at installation time (the function call itself
> is already guarded within an #ifdef/#endif block, so it seems somewhat
> optional already).
I confirm that a build with this patch gets rid of the libsystemd0
dependency in the udeb:
diff --git a/debian/rules b/debian/rules
index f1a9df9bd..bef9b2df3 100755
--- a/debian/rules
+++ b/debian/rules
@@ -71,6 +71,8 @@ define CONFARGS.udeb
--with-pool=none
--disable-readline
--disable-selinux
+ --disable-app-machineid
+ --disable-systemd-journal
endef
BUILDS :=
I looked up the impact of --disable-app-machineid and I concluded that it
should be safe to use it even if the non-udeb build has it enabled.
The option only adds a supplementary source (named "appmachineid") for lvm
to get a "system_id". The DEFAULT_SYSTEM_ID_SOURCE is "none" and it's not
overriden by what we ship as Debian configuration files. Given that it was
non-existent up-to-now, we can be pretty sure that d-i is not overriding
the lvm configuration to set global/system_id_source to "appmachineid".
man lvmsystemid has some explanation about the feature related to
"systemid" and from a quick check on my system, it looks like that
VG created by d-i do not set any system id.
Bastian, do you agree with the above assessment? If yes, can you upload
a fixed package please?
Cheers,
--
Raphaël Hertzog
Reply to: