Hello,
On 25/01/2026 01:51, yokota wrote:
About 1. we could indeed drop the amd64-specific assembly code, this
would allow following newer 7z easily without worrying about asmc-linux,
and cover bookworm.
You also needs to edit "debian/*.install" file.
Because 7zip builder uses newer feature of "dh-exec(1)".
I use "dh-exec-subst(1)" to find path to assembly-enabled executable files.
This fix might be easy because you will drops assembly code in 7zip.
Thanks!
About 2., there is indeed fragile code in reverse dependencies,
including specific detection of p7zip, e.g. I saw:
https://salsa.debian.org/qt-kde-team/kde/ark/-/commit/14e484763f37c41d8ebd1a87a826b7bff1eab7dc
https://salsa.debian.org/debian-mate-team/engrampa/-/commit/b7961f856ce613f937f9a1259d1d3b5792a2bdf4
so apparently even 7z can't be used as a straight drop-in replacement
for p7zip in older dists. We'll have to decide if we want to invest the
time and tests.
You can add more patch that newer 7zip mimics as older p7zip.
7zip text output can be find in "CPP/7zip/UI/Console/*" file.
Patch up 7zip code and output same text as p7zip.
Printing the p7zip version addendum (from
CPP/myWindows/mySplitCommandLine.cpp) may ease the transition indeed,
good idea :)
Another difference is the handling of symbolic links:
- 7zip:
disabled by default
enabled using '-snl' option
- p7zip:
enabled by default, using p7zip-specific lstat(2)-based code
disabled by undocumented '-l' option
'-snl' also available but seems no-op
We could also ease transition in <=bookworm, by enabling '-snl' by
default and re-introducing '-l' as '!-snl'.
Overall we're leaning towards a different, smoother kind of transition,
where 'p7zip' would remain the 'p7zip' package, but really would be a
minimally-patched, recent '7zip' under the hood.
That might just work.
Cheers!
Sylvain Beucler
Debian LTS Team
