Control: tags -1 wontfix
Control: close -1
On Sun, 16 Mar 2025 12:44:57 +0000 Simon McVittie <
smcv@debian.org>
wrote:
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.
Sadly that's not possible, as python3-pyzstd does not work with
compressed kernels, it cannot extract them correctly as it doesn't
support stream decompression. That's what it used before, but it never
worked. If anybody can fix python3-pyzstd to work with kernel images it
can be revisited, but it seems unlikely as upstream explicitly rejected
it in the past:
https://github.com/sergey-dryabzhinsky/python-zstd/issues/53
This is only a corner case anyway, kernel images should use zboot
instead of shipping compressed files, as firmwares cannot handle that
anyway. It's only an issue with some Ubuntu architectures other than
x86_64.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)