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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2061329
Title:
[SRU] displaycal 3.9.11-2 needs patch to work with Python 3.12
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/displaycal-py3/+bug/2061329/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
