Bug#1056204: nmu: texlive-bin_2023.20230311.66589-7

[Hilmar Preuße]

On 11/19/23 00:40, Adrian Bunk wrote:

On Sat, Nov 18, 2023 at 11:51:15PM +0100, Hilmar Preuße wrote:

On 11/18/23 20:18, Samuel Thibault wrote:

Hi all,

nmu texlive-bin_2023.20230311.66589-7 . ANY . unstable . -m "Rebuild against new 
zlib"

Thanks for filing the NMU bug.

So a binnmu of the texlive-bin source package seems needed on all archs
to fix installing texlive-binaries.

I tested if recompiling solves the issue and it does. Hence I bump severity
of the NMU bug the get a solution ASAP.

I don't see how a binNMU would solve the problem.

A proper fix would be either to:
1. patch the version check out of texlive-bin (preferred), or

I can patch out that version check as found by Samuel, but I don't see how that would solve the core dump or the SIGABRT, which was reported. I hope lua_error(L) is not the equivalent of "exit with SIGABRT". ;-)

I still suspect that something broke in the API of zlib, the zlib people are not aware of.

2. ensure texlive-bin has package dependencies that match this runtime check The zlib people, did not change the API version or created a version

statement in the depends line like "Depends: ... zlib1g (>= 1:1.3)", hence I'd add an artificial "Breaks: ... zlib1g (<= 1:1.2.3)" to my texlive-binaries package to make sure 1.3 is in place, when the new texlive-binaries comes in. Correct?

And it also might affects users directly, without proper dependencies
e.g. a bookworm -> trixie upgrade might end up with the following order
(among many other things happening during the upgrade):
1. zlib gets upgraded
2. the tex-common trigger runs
3. texlive-bin gets upgraded
If this is permitted by the dependencies, then step 2 must not fail.

Hilmar
--
Testmail

I'd rather expect that the triggers run at the end of the setup process, i.e. after all packages replaced their files. At least this was the original ideal behind them IIRC.

OpenPGP_signature.asc
Description: OpenPGP digital signature