[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1117555: RM: python3-dolfinx/1:0.9.0-7 python3-scifem/0.6.0-2



Hi,

On 10/7/25 22:19, Drew Parsons wrote:
The problem is that with the fenics packages, the different components use each other.

So, wouldn't it be better to test these three packages together.

Dependency on the virtual package, python3-nanobind-abi16, is intended to fix the situation, and is the change that has been made in unstable that I am trying to migrate.


So if I understand you correctly, the changes in unstable are exactly to prevent the current situation in the future. Good.

So at the moment when python3-basix/0.9.0-3 (built with the new python3- nanobind-abi16) tries to migrate, it tests against old python3- dolfinx/1:0.9.0-7 (build against old nanobind).  But python3- dolfinx/1:0.9.0-7 does not know that it is incompatible with python3- nanobind-abi16 (against, this is the problem fixed in unstable), and so the CI daemon does not think to try with new python3-dolfinx/1:0.9.0-8 instead.

So once python3-dolfinx/1:0.9.0-7 and python3-scifem/0.6.0-2 are cleared from testing, there well be clean slate, allowing python3-basix/0.9.0-3 to migrate together with python3-dolfinx/1:0.9.0-8 and python3- scifem/    0.10.0-1.  After that there ought to be no further issues, since python3-nanobind-abi16 will then be used to monitor these dependencies.

There are two more solutions (of which I prefer 1 as it's seems technically correct, I assume you'd prefer 2): 1) the involved packages (python3-basix if I'm right) carry a Breaks (on python3-dolfinx if I'm right) for the lifetime of forky to ensure users also don't do partial upgrades (and then the migration software will run the tests with all those binaries from unstable)
2) we manually trigger the tests with the three packages from unstable

Paul


Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature


Reply to: