Hi Graham
pyside6 will FTBFS once Python 3.14 is the default version in Debian
due to dh_missing complaining about files not being installed
anywhere. I've included a simple patch below.
Good catch - thank you!
pyside6 appears on neither of the two Python 3.14 transition trackers
[1][2]. I think that the binary packages should have (generated)
versioned dependencies on python3.
Perhaps I've missed something here - I don't believe that PySide6 has a
specific dependency on the Python version that it is being used with.
(That is, other than whatever incompatibilities might arise between
Python interpreter releases, just the same as we have with all Python
packages.) The .so it compiles are all ABI3, indicating cross
interpreter support.
As an experiment, I just ran the autopkgtests of pyside 6.9 (built with
Python 3.9 in sid) with python3.14 (python3-defaults=3.14.2-1 from
experimental). The tests pass. While these are superficial tests, doing
nothing other than checking that the modules are importable, if the .so
is importable then we don't have a cross-interpreter import problem. I
can see that is also being run on ci.d.n as part of the
experimental+unstable pseudo-excuses tests for python3-defaults.
That said, I'm aware that we are neither explicitly building against all
supported python interpreters, not testing against them.
I originally chose not to test against the non-default interpreters because
- I didn't want to accidentally couple Qt and Python transitions
- PySide6 usage is only by programs and they only ever use the default
interpreter; a failure autopkgtests on a non-default interpreter is
irrelevant to them but would still result in RC-bug-driven autoremoval
of a sizeable (and growing) tree of packages (and frankly, I don't need
the stress of that)
- if any failures did come up with non-default interpreters, I am not
confident that upstream would be responsive as they have their own
published view of supported interpreters that *does* couple Qt and
Python versions and is slower than Debian has typically been pushing, at
least for the 3.XY-add transitions. While those failures need to be
addressed eventually, that's only at the 3.XY-default transition, not
the 3.XY-add transition.
I can see from a RT perspective that not testing against the non-default
Python interpreters is suboptimal - having a signal that packages work
so the transition is good to proceed is valuable.
- Do we not already get that from the experimental pseudo-excuses use of
ci.d.n for the 3.XY-defaults transitions?
- Would adding an extra set of `flaky` tests for non-default
interpreters be a useful middle ground for this?
- Or would you rather see that import test against all supported
interpreters (and see if we regret that when we get to Python 3.15)?
regards
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ [email protected]
Debian Developer http://www.debian.org/ [email protected]
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
