[Debian-astro-maintainers] Bug#1085728: python-multipart: Make room for https://pypi.org/project/multipart/ somehow?

[Colin Watson]

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)                              [cjwatson at debian.org]