Control: tags -1 + patch Control: user de...@kali.org Control: usertags -1 + kali-patch
On Sun, 17 Jul 2022 05:50:20 +0200 Cyril Brulebois <k...@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