Hi Felipe Am 30.01.20 um 22:30 schrieb Felipe Sateler: > > > On Thu, Jan 30, 2020 at 1:39 PM Michael Biebl <bi...@debian.org > <mailto:bi...@debian.org>> wrote: > > Am 28.01.20 um 17:27 schrieb Ansgar: > > On Tue, 2020-01-28 at 16:51 +0100, Michael Biebl wrote: > >> Am 28.01.20 um 14:59 schrieb Ansgar: > >>> I tried linking systemd-{sysusers,tmpfiles} statically against > >>> systemd's private library earlier this month. It increases the > >>> binaries size by ~100 kB (compared to Installed-Size: 14.2 MB of > >>> systemd that is just one percent). > >> > >> Is that 100K per binary? > > > > I checked my notes at it was 100 kB per binary: they are 212 kB larger > > (sysusers 51 kB → 137 kB, tmpfiles 84 kB → 212 kB); I tested with > > systemd 243-8. > > > > It might be possible to make it a bit smaller if one was to somehow > > link libsystemd0 for functions available there (libsystemd-shared > > currently duplicates those). > > > That is not possible. There is global state that is not to be shared. > See https://github.com/systemd/systemd/pull/3516#issuecomment-227482524
What's your thought on how to solve this libsystemd-shared issue should we consider splitting out systemd-{sysusers,tmpfiles} - link statically (and carry a downstream patch for eternity) - move libsystemd-shared to systemd-utils and risk the breakage that can result from a partial/aborted upgrade - copy, instead of move, the binaries + libsystemd-shared and make the resulting systemd-utils package Conflict with systemd (instead of having systemd depend on systemd-utils) - something else? Regards, Michael
signature.asc
Description: OpenPGP digital signature