Source: odoo Version: 16.0.0+dfsg.2-2 Severity: wishlist The odoo package has recently added a dependency on python3-pypdf2. Last January the following bug was filed against all packages using python3-pypdf2:
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) To transition a given package: - run tests with as complete coverage as possible and note the PendingDeprecation warnings - for each warning, patch the upstream line as recommended - ensure that the tests pass without PendingDeprecationWarnings - convert from "PyPDF2" to "pypdf" on any import or scoped reference in python - update dependency indicators in upstream metadata annotations (e.g. pyproject.toml, setup.cfg, etc) - update dependency indicators in debian packaging (from python3-pypdf2 to python3-pypdf). - run the tests again I'm currently in the process of updating all these bugs with: 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. Scott K
