Looking at CVE-2024-5569 and the potential of future CVEs,
I wonder whether there is any reason why reverse dependencies
still need this package or whether they could use the version
vendored in src:python3.*

If there is a reason, feel free to lower the severity but
keep the bug open as wontfix to document it (or close the
bug with a package description update).

Control: severity -1 normal
Control: tags -1 wontfix
_possible_ to avoid it in many cases, but that will get easier as older
versions of Python fall out of upstream support and I'm not convinced
it's worth the effort to accelerate that.  However, it's also not clear
that the use of this package will naturally fall to zero over time in
upstream packages due to rolling addition of features.  I don't think
it's viable to completely eliminate this package.

  $ reverse-depends -b src:python-zipp
  Reverse-Testsuite-Triggers
  ==========================
  * python-mercantile             (for python3-zipp)

  Reverse-Build-Depends
  =====================
  * cpplint                       (for python3-zipp)
  * importlib-resources           (for python3-zipp)
  * python-importlib-metadata     (for python3-zipp)

  Reverse-Build-Depends-Indep
  ===========================
  * python-mercantile             (for python3-zipp)

  $ reverse-depends src:python-zipp
  Reverse-Depends
  ===============
  * python3-catalogue [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x]
  * python3-evtx                  (for python3-zipp)
  * python3-importlib-metadata    (for python3-zipp)
  * python3-importlib-resources   (for python3-zipp)
  * python3-mercantile            (for python3-zipp)
  * python3-setuptools            (for python3-zipp)

Going through each of these:

 * cpplint

   Might be easy to remove; it's in test-requirements, but it's hard to
   see why.

 * importlib-resources

   I removed its explicit run-time Depends, although pybuild still adds
   a dependency on "python3-zipp | python3-supported-min (>= 3.10)" to
   match the upstream requirements.

   There's still a Build-Depends, because the test suite explicitly uses
   zipp.CompleteDirs which is not public API in zipfile.

 * python-catalogue

   Actually just "python3-zipp | python3-supported-min (>= 3.8)", so
   should go away once dh-python >= 6.20240825 is released and it's
   rebuild with that since that suppresses dependencies that would be
   satisfied by python3 >= 3.9.

 * python-evtx

   Might be easy to remove; it's in setup.py, but it's hard to see why.

 * python-importlib-metadata

   Would require patching, since it explicitly uses zipp without a
   zipfile alternative.

 * python-mercantile

   Would require patching.

 * setuptools

   I think this has a dependency because it vendors importlib_metadata.

The big deal here will be
https://salsa.debian.org/python-team/tools/dh-python/-/commit/4baa3c5714cebe0ffd457939ec4e7048462c650b;
that should make a lot of the dependencies on
python3-importlib-{metadata,resources} go away, and then this will be a
lot easier.  But there'd still be lots of stragglers.

More broadly, https://pypi.org/project/zipp/ indicates that this package
isn't just a static backport, but can provide new features to older
versions of Python ahead of the version in the standard library.  This
suggests to me that it may not be the sort of thing that ever completely
goes away; if a package needs something from (say) zipp 3.18 today then
it won't get that until Python 3.13 is the default, so upstreams may
continue adding dependencies on it.  For example,
https://github.com/python/importlib_metadata/commit/56b61b3dd90df2dba2da445a8386029b54fdebf3
recently added a dependency on zipp>=3.20.  The same sort of thing is
true for importlib_resources and importlib_metadata, which each have
their own compatibility tables with the standard library.