Hello Hiroshi,
On 01/04/2026 17:24, Sylvain Beucler wrote:
Also, back to the 7zip front, I contacted the previous bookworm-
backports uploaders to plan sync'ing with trixie, to avoid upgrade
issues for bpo users.
Working on the backport raised 2 issues:
* p7zip: 7zip/trixie has too strict replacements for the p7zip->7zip
transition, making it impossible to fit in any update.
This may result in temporary conflicts on /usr/bin/7z* during upgrades.
Would this 7zip/trixie fix be OK?
Package: 7zip
...
-Breaks: p7zip-full (<= 16.02+dfsg-8),
- p7zip (<= 16.02+dfsg-8)
-Replaces: p7zip-full (<= 16.02+dfsg-8),
- p7zip (<= 16.02+dfsg-8)
+Breaks: p7zip-full (<< 16.02+transitional.1),
+ p7zip (<< 16.02+transitional.1)
+Replaces: p7zip-full (<< 16.02+transitional.1),
+ p7zip (<< 16.02+transitional.1)
* 7zip: I uploaded 7zip-25/bookworm to pu, but this gets in the way of
the 7zip -> 7zip+7zip-standalone split
(cf. #1050118, /usr/bin/7zz conflict):
Package: 7zip-standalone
Replaces: 7zip (<< 23.01+dfsg-4~)
I asked the SRMs to reject my upload (if it's not too late) so we may
use a more complex version scheme such as:
bookworm: 22.01+dfsg-8+deb12u1
proposal: 22.01+really25.01+dfsg-0+deb12u1
trixie: 25.01+dfsg-1~deb13u1
Or, always update 7zip-standalone/trixie with a Break on prior versions:
-Replaces: 7zip (<< 23.01+dfsg-4~)
+Replaces: 7zip (<< 25.01+dfsg-1~)
What do you think?
Cheers!
Sylvain Beucler
Debian LTS Team
