During the Debian 11 release cycle, we did a Xen upload at the same time
when a transition of default Python version (from 3.8 to 3.9) was
happening. This exposed a problem: Our xen-utils-V package just depended on
'python3'.
Why was this a problem? We ship a compiled extension, which gets built for
the *default* Python version in the system. In this case it was the
xenfsimage.cpython-39-x86_64-linux-gnu.so file (note the 39 in the name).
Having just the quite generic 'python3' dependency allowed our packages to
enter Debian testing before the transition of default Python version (from
3.8 to 3.9) did. As a result, the xenfsimage library could not be found,
because the user system would still be looking for [...]cpython-38[...].
To generate correct dependencies, dh-python >= 5.
20211016 (which
includes a fix for #980303) is needed.
In the above case, the correct dependencies that would need to be added
are: 'python3 (<< 3.10), python3 (>= 3.9~)'. Having these dependencies in
place would make sure our packages enter testing at the same time as the
default change to Python would.
The actual patch in here is quite small, but not easy to understand as
multiple other bugs are also intertwined, so here follows more explanation.
First, this patch reverts
1ca529cc3c ("debian/control: fix xen-utils-4.14
python3 dependency"), which was a workaround for a missing python3
dependency in the xen-utils-V package. This problem happened due to
the dynamic ${python3:Depends} back in) is a prerequisite for the second part
below.
Second this patch adds scanning of the private directory
"/usr/lib/xen-$(upstream_version)/lib/python" for dh-python to detect
our private python extension and generate proper version dependencies
for python3. This unfortunately was broken in dh-python (#980303), but
is fixed since 5.
20211016.
This part is the fix for #976597.
We were thinking about adding a build dependency to dh-python >=
5.
20211016 to the xen source package, but decided to omit the version
from the dependency for the following reasons:
* A dh-python with all relevant fixes is meanwhile in unstable and
testing.
* We wanted to make backporting xen to bullseye easy and dh-python >=
5.
20211016 is not in bullseye. Adding the versioned dependency would
mean more manual work while doing the backport.
We believe this is safe to do for the following reasons:
* When building for unstable or testing in an up-to-date chroot there
should be no issues as all relevant bugs in dh-python are fixed.
* When building a backport for bullseye, proper version dependencies for
python3 will not be generated, but also have not been generated in the
past, so this is not a regression. And, the default python3 version in
bullseye will very likely never change.
* The revert of
1ca529cc3c might be seen as a problem as the dependency
on python3 in xen-utils might be missing when compiled for bullseye.
However this luckily does not happen because of our additional scan
for private python extension in this commit. While the bullseye
dh-python is buggy in a way that it doesn't generate proper version
dependencies for python3 it still detects python3 usage and adds a
'python3' dependency.
Signed-off-by: Maximilian Engelhardt <maxi@daemonizer.de>
[ adding first three introductory paragraphs in the commit message ]
Signed-off-by: Hans van Kranenburg <hans@knorrie.org>
projects / xen.git / commitdiff