#1141379 dh-python should generate strict python3 dependencies for libpython dependencies

Package:
dh-python
Source:
dh-python
Submitter:
Adrian Bunk
Date:
2026-08-04 13:45:01 UTC
Severity:
normal
#1141379#5
Date:
2026-07-03 16:46:38 UTC
From:
To:
Unstable:

Package: python3-bornagain
Version: 24.1+ds3-1
Depends: ..., libpython3.14 (>= 3.14.1), ...


Testing:

Package: python3-bornagain
Version: 23.0-7
Depends: ..., libpython3.13 (>= 3.13.0~rc3), ...


This results in test failures both when testing for python3-defaults
migration and for bornagain migration, since using libpython in a
different version of the python interpreter segfaults.


The problem is not limited to autopkgtests, the lack of package
dependencies also means the packages can migrate at different
times to testing once no blocker remains for one package.

It's even worse when not caught by the autopkgtest:
kicad would be an example for a package with a libpython dependency
that does not seem to be tested by the autopkgtest.

In addition to testing migration, such a missing dependency
could also cause problems when upgrading to a new stable release.


A libpython3.14 dependency like in python3-bornagain or kicad should
additionally result in dependencies
  python3 (>= 3.14~), python3 (<< 3.15)
#1141379#20
Date:
2026-07-07 16:32:38 UTC
From:
To:
Bonus points if that would also be done for libboost-python*-py3*

Additional bonus points if this could give a FTBFS instead of having
something like the following broken package in the archive:

  Package: kig
  Version: 4:26.04.0-1+b1
  Architecture: amd64
  Depends: ..., libboost-python1.90.0-py313,..., libpython3.14 (>= 3.14.1),...


cu
Adrian
#1141379#25
Date:
2026-07-09 09:12:23 UTC
From:
To:
Hi Adrian

Please file a bug against src:kig with the details.

Regards
Graham
#1141379#30
Date:
2026-07-09 09:58:07 UTC
From:
To:
I was trying to fix it by getting rid of some cruft, but I'll just
submit the small change I already have.

cu
Adrian
#1141379#41
Date:
2026-08-03 10:27:16 UTC
From:
To:
¡Hola Adrian!

El 2026-07-03 a las 19:46 +0300, Adrian Bunk escribió:

I'm not sure this is the right approach. Wouldn't it be better to create
the version specific bornagain extensions for each of the available
python3?

As packaged, bornagain will fail if the user runs a different
python version than the one bornagain was built against, that's a bit
more problematic for the changes of the default version. But, even today,
with bornagain built against python3.14, and having python3.14 as the
default, a user that starts python3.13 will get some errors when trying
to use bornagain.

So, maybe, we want python packages that produce extensions to support
multipython, and discourage extensions that are built only for the
default python3.

Happy hacking,
#1141379#46
Date:
2026-08-04 07:07:30 UTC
From:
To:
¡Hola!

El 2026-08-03 a las 12:27 +0200, Maximiliano Curia escribió:

I just sent a mr (https://salsa.debian.org/science-team/bornagain/-/merge_requests/2) to bornagain, that produces the libraries linked against each supported python3 version. I think that's better for packages like bornagain.

Happy hacking,
#1141379#51
Date:
2026-08-04 13:44:09 UTC
From:
To:
This only makes a difference during a python transition in
unstable/testing.

More relevant for users is that bornagain in forky will not support
python3.13 in trixie, the same issue exists during upgrade to a new
stable release.

cu
Adrian