Bug#1117043: transition: vtk9

[Adrian Bunk <bunk@debian.org>]

On Wed, Oct 22, 2025 at 10:25:36AM +0200, Emilio Pozuelo Monfort wrote:
> On 20/10/2025 18:39, Dominique Belhachemi wrote:
> > > Can you take a look at the autopkgtests regressions? [1]. camitk probably needs
> > > to be removed from testing, but I don't know about the rest.
> > > 
> > Please remove them from testing.
> > Also, python3-vtk-dicom was rebuilt, but the test framework is still
> > using the older version
> > python3-vtk-dicom (0.8.17-1+b1) instead of
> > python3-vtk-dicom (0.8.17-1+b2).
> 
> Does python3-vtk-dicom (and maybe other python3-vtk9 rdeps) need a stricter
> dependency? From its autopkgtest log:
> 
>  48s Testing with python3.13:
>  48s Traceback (most recent call last):
>  48s   File "<string>", line 1, in <module>
>  48s     import vtkdicom; print(vtkdicom)
>  48s     ^^^^^^^^^^^^^^^
>  48s   File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 2,
> in <module>
>  48s     from .vtkDICOM import *
>  48s ImportError: Initialization failed for vtkDICOM, not compatible with
> vtkmodules.vtkCommonCore
> 
> If the vtk python module is changing some kind of ABI, then there should be
> appropriate dependencies on the rdeps so they enforce a compatible version.
> See for example python3-numpy with python3-numpy.*-abi.*

This is the old problem that the release team wants smooth transitions,
but using different so-versions of a library in a binary is usually
not safe.

And no, symbol versions won't solve that in all cases.

https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/65358838/log.gz
 47s Setting up libvtk9.5:amd64 (9.5.2+dfsg2-1) ...
 47s Setting up libvtk9.3:amd64 (9.3.0+dfsg1-7) ...

The proper fix would be:
  Package: libvtk9.5
  Breaks: libvtk9.3

> Cheers,
> Emilio

cu
Adrian