This bug is starting to accumulate other Python 3.13-related bugs that it blocks, so I'd like to agree a plan.
On Tue, Oct 22, 2024 at 12:03:13PM +0100, Colin Watson wrote: > Please see https://github.com/pypa/packaging-problems/issues/818 for > background on this. This has been mostly sorted out upstream. It should now be possible to use both multipart and python-multipart in parallel, and python-multipart has some transitional support for projects that do `import multipart` as long as only python-multipart is installed. In a Debian context, this is a stricter criterion, because it's more likely to have both packages installed when they're system packages than when they're only in a project-specific virtualenv; but it should still be manageable enough. I believe these are all the reverse-dependencies involved, and I've CCed all the affected maintainers (assuming they read their @packages.debian.org email, anyway): $ reverse-depends src:python-multipart Reverse-Recommends ================== * python3-moto (for python3-multipart) * python3-starlette (for python3-multipart) Reverse-Depends =============== * matrix-synapse [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x] * python3-asgi-csrf (for python3-multipart) * python3-gavo (for python3-multipart) Packages without architectures listed are reverse-dependencies in: all, amd64, arm64, armel, armhf, i386, mips64el, ppc64el, riscv64, s390x $ reverse-depends -b src:python-multipart Reverse-Testsuite-Triggers ========================== * asgi-csrf (for python3-multipart) * python-moto (for python3-multipart) Reverse-Build-Depends ===================== * fastapi (for python3-multipart) * matrix-synapse (for python3-multipart) * python-curies (for python3-multipart) * starlette (for python3-multipart) Reverse-Build-Depends-Indep =========================== * asgi-csrf (for python3-multipart) * python-moto (for python3-multipart) So, my proposal is as follows: * Rename python-multipart source package to python-python-multipart, and its binary package to python3-python-multipart. Yes, it's a bit ugly, but there are currently 13 other binary packages in the archive whose names start with "python3-python-", so there's precedent, and it matches the way we usually transform PyPI names into Debian package names. python3-python-multipart should have Breaks/Replaces: python3-multipart (<< 0.1) (the oldest release of https://pypi.org/project/multipart/, which is also newer than any release of https://pypi.org/project/python-multipart/). * Since there are only seven other source packages involved (asgi-csrf, fastapi, gavodachs, matrix-synapse, python-curies, python-moto, and starlette), it should be fairly straightforward to update all their Depends/Recommends/Build-Depends/Build-Depends-Indep/Testsuite-Triggers to use python3-python-multipart. * Once all this has reached testing, the way will be clear to upload a new python-multipart source package based on https://pypi.org/project/multipart/, building a new python3-multipart binary package. Conveniently, the version numbers of multipart and python-multipart upstream are such that this won't require an epoch. The new python3-multipart binary package should declare Breaks on old versions of all the packages where we had to update run-time dependencies (matrix-synapse, python3-asgi-csrf, python3-gavo, python3-moto, and python3-starlette). How does this sound? Sandro, I'd especially like to get your feedback on this, because doing a source+binary package rename in an NMU sounds ... painful, especially if it turns out later that there wasn't consensus. Thanks, -- Colin Watson (he/him) [cjwat...@debian.org]
