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