Hi, During the python3.14 as default python3 interpreter transition, vtk9 has been binNMU'ed, resulting in the package building libvtkWrappingPythonCore3.14-9.5.so.1. However that can cause rdeps to fail, as demonstrated in one autopkgtest [1]: 332s ERROR: TestFemApp (unittest.loader._FailedTest.TestFemApp) 332s ---------------------------------------------------------------------- 332s ImportError: Failed to import test module: TestFemApp 332s Traceback (most recent call last): 332s File "/usr/lib/python3.13/unittest/loader.py", line 137, in loadTestsFromName 332s module = __import__(module_name) 332s File "/usr/share/freecad/Mod/Fem/TestFemApp.py", line 33, in <module> 332s from femtest.app.test_mesh import TestMeshCommon as FemTest07 332s File "/usr/share/freecad/Mod/Fem/femtest/app/test_mesh.py", line 33, in <module> 332s import Fem 332s ImportError: libvtkWrappingPythonCore3.13-9.5.so.1: cannot open shared object file: No such file or directory One possible easy solution would be to build vtk9 against all supported python3 versions, thus during the transition libvtk9 would have both 3.13 and 3.14 builds, and it would be dropped once the older version is no longer "supported" (i.e. included in python3-all). Another option would be to have some dependencies, e.g. through a Provides: libvtkwrapping-python3.XX and corresponding deps in rdeps. Cheers, Emilio [1] https://ci.debian.net/data/autopkgtest/testing/amd64/f/freecad/73101911/log.gz
Building vtk9 for all supported python is a grand challenge because of the cmake problem: cmake does not easily build support for multiple python version. It can manage selection of version, but not multiple in the same build. Building for non-default python could possibly be set up, but it's a bit of effort, and I'm not sure it wouldn't give auxiliary problems, e.g. VTK C++ modules (not python modules) linking to a specific libpython3.Y.so, which can't be managed so easily. e.g. Rendering/PythonContext2D, /usr/lib/x86_64-linux-gnu/libvtkPythonContext2D-9.6.so links to libvtkWrappingPythonCore3.14-9.6.so.1 Your second idea might be the only practical way to manage it, set up a dummy dependency so vtk9 catches the python default transitions.
Control: reassign -1 dh-python Control: forcemerge 1141379 -1 Control: affects 1141379 src:vtk9 python3-vtk9 The better solution is for dh_python3 to emit dependencies python3 (>= 3.14~), python3 (<< 3.15) I'm merging this with the existing bug for that, there is no point in working around this issue in a gazillion packages. freecad-python3 has the same issue (though it might not be tested by an autopkgtest: Depends: ..., libpython3.14 (>= 3.14.1),... Without the autopkgtest blocking due to this issue in vtk9 freecad would have already migrated, resulting in freecad-python3 segfaulting in testing. cu Adrian
Hi, I was aware of the existing dh-python bug, but decided to file this as a separate issue as I don't think the situation is the same. I agree that a more general solution would be better. I'm not sure that your proposal suits all cases (including this one). For a python module package, your proposal is fine. However for a library package that links against libpython, not so much. See e.g. libfontforge4 or libmailutils9t64. I don't think those should depend on python3. Breaks or Conflicts could be another option to ensure proper upgrades, but that may cause upgrade issues and unintended package removals? That looks like a different case (i.e. python module or app) than vtk9, covered by the previous dh-python bug, where I agree a tighter python3 dependency could be useful. Cheers, Emilio
Hi Emilio, fair point that Breaks: python3 (<< 3.14~), python3 (>= 3.15~) might be better than my suggestion. I'd be more worried about upgrade issues cause by maintainer scripts (e.g. postinst) calling programs that are non-functional during an upgrade. freecad-python3 -> libfreecad-python3 -> libnglib-6.2t64 -> libpython3.13 cu Adrian