Package: release.debian.org Followup-For: Bug #1111004 I dug in a little further to follow up your point about cffi. dolfinx (python3-dolfinx-real) catches the cffi abi but not nanobind.
As you mentioned, nanobind now (>= 2.8.0-1) has the same mechanism for dh_python to add the abi dependency that cffi uses, that is, python3-nanobind now provides /usr/share/python3/dist/python3-nanobind As I mentioned, the fenics packages use nanobind at build-time not runtime. So their pyproject.toml declare [build-system] requires = ["nanobind>=2.0.0"] but not dependencies = ["nanobind"] dolfinx does have dependencies = ["cffi"], which is why dh_python3 catches the cffi abi. I think upstream is doing the right thing declaring nanobind in build-system not dependencies. But for debian packaging purpose it's convenient for us to use dh_python3, which means using pyproject.toml dependencies. Can debate separately if dh_python3 ought add a Build-Using mechanism that reads [build-system], but that will be somewhat challenging to implement. The simplest workaround for us at this point is just to patch our fenics packages to add nanobind to pyproject.toml dependencies. (basix adds an extra layer of confusion by providing two pyproject.toml, toplevel and python subdir. We use the python subdir). So, the fenics packages are ready for the nanobind transition (now 2.9.0). We can upload the fenics patches before or after the nanobind transition begins. (uploading after would mean no binNMU would be needed)
