On Thu, 26 Jan 2023 16:39:39 -0500 Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote: > As noted in https://bugs.debian.org/1028559, upstream for the PyPDF2 > Python module has moved to the "pypdf" namespace. > > Correspondingly, there is a new python3-pypdf package in debian > unstable. > > The packages listed above all currently depend on (or recommend) PyPDF2, > but probably should move to the updated version. When all these bug > reports are closed, we can consider removing the pypdf2 source package > and python3-pypdf2 from debian. > > The migration should be relatively straightforward; much of the API > remains the same, just under the "pypdf" module name instead of the > "PyPDF2" module name. Where the API differs, the version of PyPDF2 > currently in debian testing/unstable (2.12.1-3) emits a > PendingDeprecationWarning wherever a piece of the API will break. > > For example: > > foo.py:76: PendingDeprecationWarning: getObject is deprecated and will be removed in PyPDF2 3.0.0. Use get_object instead. > > (PyPDF2 version 3.x is basically a terminal version of PyPDF2, and pypdf > takes over from 3.1.x onward; PyPDF2 version 3.x will not enter debian, > as it is an API break from 2.x, and pypdf 3.x supercedes it)
As we approach the first anniversary for this bug, an update: I've recently adopted pypdf and pypdf2 into the Debian Python Team in response to an RFA for both packages. As these are somewhat security sensitive packages (among my first acts after adopting the packages was to upload proposed updates for both to address minor security issues in Bookworm in the next point release - same bug in both), I do not think we should release pypdf2 in Trixie and have filed an RC bug to that effect. If you want this package to be in Trixie, you will need to use pypdf instead of pypdf2. There is a new upstream release that supports this transition, but packaging it will be non-trivial. Scott K
signature.asc
Description: This is a digitally signed message part.
