Control: retitle -1 shiboken2 - shiboken_helpers.cmake breaks with every Python transition Disclaimer: I didn't check to see if upstream 5.15.3 fixed this issue. Yuri D'Elia <wavexx@thregr.org> writes: > On Wed, Apr 13 2022, Nicholas D Steeves wrote: >> I understand, and agree that the issue is real, and that a rebuild is >> required. A binNMU is the most expedient solution ;-) Please read >> "What are binNMUs?" at the link provided above... > > Yes, but I wouldn't call this "expedient", since ... > Expedient means fast. [1. Optionally check what happens locally] 2. Schedule a binNMU. Unfortunately it won't work in this case. The pyside2 build currently in unstable correctly iterated over supported Python versions, and both libshiboken2-py3-5.15 and libshiboken2-dev contain both Python 3.9 and 3.10 variants...but that's not good enough, because shiboken_helpers.cmake doesn't appear to support multiple Python versions, and isn't choosing the right (ie: Debian's python3-default) version. Yuri, I see what you mean now, it seems the fastest way to resolve this would be to statically declare a dependency on python3.10-dev everywhere in the package, but by doing this the Debian pyside2 package would lose early detection of FTBFS and failing unit tests with future Python versions, which means upstream might not receive early enough notification, which means pyside2 would risk being cut from the next Debian release if a Python transition happens right before the freeze. The backported py3.10 support patches already in the pyside2 package are evidence that the existing approach has value. [snip] > Answering this for an hypothetical 3.11 transition, the answer would > similarly be "likely doesn't matter - it's worth attempting a build and > hope for the best, because the current version is broken". And with the above context, your pragmatic point makes sense in a "perfect is the enemy of the good" sense :-) Unfortunately your proposed resolution won't solve what now appears to be the root of the problem: shiboken_helpers.cmake doesn't appear to support multiple installed Python versions, and will necessarily break with every Python transition. It seems to me that that cmake file should be generated during pyside2's build to enable runtime detection of the support for all Python versions that were compiled into the pyside2 libraries. Alternatively, as a less desirable option, that cmake file could be modified in override_dh_auto_install (or somewhere more appropriate) to exclusively support the current python3-default version. In both cases, I'm assuming that the compiled py39 and py310 libs are functional. >> As a general principle, I worry that this would either reduce >> functionality and/or debugging, or introduce regression potential, so >> this is not a change I'm willing to make as a team member and not >> as one of the primary maintainers/uploaders of pyside2. > > I understand this. And the documentation around this define is lacking > as well. Looking at the sources, it does seem to reduce the number of > exported methods, so it is fair to say we might have users that expect > the full API to be available and would break if used... Thank you for your help investigating this option! Unfortunately I'm out of time for the near future, but if you'd like I can upload an untested 5.15.3 package to experimental for you to test. To be honest, I won't have time to make the cmake fix for what isn't even one of my packages. Sorry. Sincerely, Nicholas
Attachment:
signature.asc
Description: PGP signature