On Sat, Mar 30, 2024 at 05:59:36PM -0000, Daniel Alley wrote:
It appears that libsystemd links to libraries for lzma/xz, bzip2, gzip and also zstd, because some systemd utilities provide them as options in various different contexts (but not consistently, zstd for instance is seemingly supported by some utilities and not by others, and I see some code such as [0] that doesn't account for it)
I'm sure having all of those different options available is nice in some context or another, but how unrealistic would it be to pare that back to a few slightly more opinionated and consistent choices? Bzip2 for instance isn't particularly good on *any* metric, are there legacy / ecosystem reasons that are sufficiently important for libsystemd to be dragging it around? libsystemd linking 4 different compression libraries does seem a bit excessive (if it can be helped).
[0] https://github.com/systemd/systemd/blob/3799fa803efb04cdd1f1b239c6c64803fe85...
libsystemd is linked to compression libraries primarly because those compressors are options for journald files, and we generally want to mainain the property that all journal files from the past, as well as journal files from other systems, can be read by later journal code.
(bzip2 is an exception here. It is only used by systemd-importd and related tools, so libsystemd was never linked to it, IIRC.)
In recent systemd versions, dlopen is used for various compression libraries and other libraries, so they'll be opportunistically loaded if needed, effectively making those dependencies optional at runtime.
Conversions to use dlopen require a bit of boilerplate code and make the code less readable, so we only would to them if there was a reason. Usually, this reason was size and/or the dependency tree. Compression libraries are very small and have no dependencies, so it wasn't considered important to use dlopen for them. But now that there's a new motivation, as mentioned elsewhere in the thread, we'll load pretty much all dependencies of libsystemd via dlopen.
Zbyszek