Bug#1100629: systemd-ukify: ability to use a different zstd implementation
Simon McVittie
smcv at debian.org
Sun Mar 16 12:44:57 GMT 2025
Package: systemd-ukify
Version: 257.4-3
Severity: wishlist
Tags: upstream
systemd-ukify currently supports zstd decompression by using
python3-zstandard, which is a hard dependency; but python3-zstandard
seems to require source changes every time libzstd is upgraded as a
result of having been designed with a vendored libzstd in mind
(#1100475) which makes it more fragile than seems ideal, especially if
the long-term goal is for Debian's boot process to make more use of UKIs
in future.
Looking at the source of systemd-ukify, it seems like it only makes a
very simple use of this module: import the module, and decompress one
compressed binary blob into an uncompressed byte array in RAM. This
could presumably be done equally well with any implementation of zstd.
Perhaps it would be worthwhile to have a code path that implements zstd
decompression by using python3-pyzstd (which is somewhat higher-popcon
than python3-zstandard at the moment), or python3-zstd (although that
one is lower-popcon), or by invoking the zstd CLI tool (which is a
Recommends of initramfs-tools-core) via subprocess? That would make it
easier to swap between the implementations if one of them has
problematic properties.
smcv
More information about the Pkg-systemd-maintainers
mailing list