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