Comment 13 for bug 2061329

Thank you for working on this!

I think this is really a different upstream bug though. The current fix is just kicking the can down the road. We don't hardcode versioned dependencies for what we ship with, because that would lead to brittle packaging that breaks every package when Python is updated in the archive. Doing so within the code itself is equivalently problematic.

The real issue here is that there's a hardcoded version check which is inappropriate for our packaging. Instead, this check should be removed. Where behaviour must change based on the Python version, then that's fine, but it should arrange to use the latest behaviour for future versions. For example:

# Using additional redundant checks to make my point in
# this review clear; I wouldn't do this in real code
if dependency_version < 3:
    do_original_behaviour()
elif 3 <= dependency_version < 5:
    do_intermediate_behaviour()
elif dependency_version >= 5:
    do_latest_behaviour()

This way, the code and therefore the final package will continue to work with newer dependency versions without requiring any further intervention, which is suitable for a distribution that contains thousands of packages.

I see a concrete historical real world example where following this pattern would have caused problems. Python 3.11 was added to 22.04 in an SRU into universe. If a depending package was hardcoded to require the Python 3.10 that 22.04 originally exclusively shipped, then it would unnecessarily break against Python 3.11 on 22.04 after that SRU. If all depending packages were brittle in this way, the SRU wouldn't have worked at all without being forced to individually tweak all of those packages, for no good reason.

I would suggest to upstream that they follow this pattern to prevent issues for distribution packagers. It will also save them work every time a dependency version is bumped. Whether they agree for their case or not, our distribution packaging must be less brittle than this.

Please:

1) Fix the development release to not be brittle in this way, so it won't unnecessarily break if Python is updated in a way that doesn't break its API in a way that matters to this package.

2) Fix the SRU upload to also not be brittle in this way, so it won't unnecessarily break against a newer version of Python were we to add it to 24.04 during its lifetime, as we did for 22.04. For example, you could the patch you're adding so it works for all future Python versions, not just 3.12.

SRU process requires the development release also be fixed, and the current fix will automatically break the moment the development release moves to Python 3.13 currently in oracular-proposed; hence my requirement for 1 above, before we can land 2.

> ++@pytest.mark.skip(reason="Test segfaults with python 3.12 - further investigation
required.")

3) This also needs some further explanation, please. Is this related to "since it could crash upon closure", or something else? What's the status of this? Are you proposing this SRU on the basis that it's definitely better than the current state? All of this should be documented, please.