Bug#1141379: dh-python should generate strict python3 dependencies for libpython dependencies
Adrian Bunk <[email protected]> Tue, 4 Aug 2026 16:44:09 +0300
| Newsgroups | gmane.linux.debian.devel.bugs.rc |
|---|---|
| Message-ID | <anHsqd0MWciGBP75@localhost> |
On Mon, Aug 03, 2026 at 12:27:16PM +0200, Maximiliano Curia wrote: > ¡Hola Adrian! > > El 2026-07-03 a las 19:46 +0300, Adrian Bunk escribió: > > Package: dh-python > > Version: 7.20260623 > > Severity: serious > > Control: affects -1 python3-bornagain src:bornagain > > > > 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) > > 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. 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. > Happy hacking, cu Adrian