Hi Adrian (2026.11.03_05:21:05_+0000)
On Tue, Oct 20, 2026 at 01:33:09PM +0000, Stefano Rivera wrote:
...
I note that the version in unstable doesn't include these files, and it
isn't immediately obvious to me where the regression is. Probably in
setuptools.
...
The regression is in dh-python.
You broke something that Piotr added intentionally 11 years ago,
and based on your comment that was unintentional.
This message is missing a lot of context. Here's how I understand this
set of bugs unfolding:
1. Some upstreams don't think too much about what they install. I don't
think pip has any protection for packages installing over each
other, and this doesn't seem to have been an issue.
2. 11 years ago dh_python3 started to delete "test" and "tests" directories in
dist-packages.
https://salsa.debian.org/python-team/tools/dh-python/-/commit/7536d5a9041131dab2156450ebb1cd618b87cf1a
3. This was later extended to delete ".*" directories too.
4. We prepared for the python 3.15 transition, and hit a few snags:
1. Packages building differently under Python 3.14 and 3.15. This
only shows up when we have 2 supported Python versions and the
trees can't be merged.
2. Packages buliting twice in the same directory started to install
build artifacts from the first build in the second install. This
is the likely setuptools regression I described above.
Setuptools used to have some heuristic defences against this. The
"finder" system had a blocklist of words that wouldn't be found
unless explicitly requested. For a few reasons (that I can't
recall right now, and I really can't be bothered to go digging
for) this has not worked reliably in Debian in the past, even
though we have contributed words to them.
Building twice in a dirty tree is something that CI-centric
upstreams don't do very much, but we do during Python transitions.
So we're typically on the front line for these issues.
5. These issues and proposed solutions were discussed on MRs and
#debian-python IRC. I think there was reasonable consensus for them,
so I find your tone here rather inappropriate. I expect you wouldn't
have seen those discussions, so I do understand it, but it's still
not really in the spirit of collaboration.
6. To resolve 4.1, after expermenting with ways to merge them, we
dedided to blow up rather than leave anything unmerged. This would make
the issue clear to the maintainer who could decide on the right thing
to do, rather than leaving a messy install tree that likely nobody
would notice.
https://salsa.debian.org/python-team/tools/dh-python/-/commit/00a6dac429b9e7d6cff129c5645e0658cef1a286
5. To resolve 4.2 we decided to blow up if these issues were detected.
I also proposed an approach where we build wheels from isolated
builds of sdists:
https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/100
But that's likely to have more unforseen outcames (that are harder to
detect) than this approach. We still should do this, but with more
testing and diff-review. Not something to figure out during the start
of a transition.
I replaced the code that deleted test and tests directories with
something that threw an error if any of a range of module names was
detected. This is the change you are referencing, and yes it causes a
regression for packages that used to install a test/tests module.
https://salsa.debian.org/python-team/tools/dh-python/-/commit/7ce9edd0d3568010e391e299a10057e37e1a81f3
For the wide range of build directory names that I wanted to detecet,
it wouldn't make sense to just delete the directories silently.
Throwing errors is a much better way to get the individual review
that these cases should have. So, that's what I did.
6. ".*" directories started to clash with both 3.14 and 3.15 supported,
because the cleanup step from 2 was applied before the merge. We
solved this by sammarily deleting ".*" directories earlier. I'm not
sure why this wasn't as much of an issue in previous Python
transitions.
https://salsa.debian.org/python-team/tools/dh-python/-/commit/5b9b7185b9f76b4bf076ee6583c4d6bc95cf87cd
There was a window where we simply didn't delete these, but blew up
(4.1 above), but deleting them was clearly the best option, so we
re-instated this.
https://salsa.debian.org/python-team/tools/dh-python/-/commit/61aba7744f956c4ad0cdc8bcbea259bb93671b3b
Stefano
--
Stefano Rivera
http://tumbleweed.org.za/
+1 415 683 3272