[Python-modules-team] Bug#886291: Debian package transition: Rename package and reuse old name with new content

[Simon McVittie]

On Sat, 18 Aug 2018 at 16:31:37 +0200, Alexis Murzeau wrote:
> To fix #886291, we should:
> - Rename python3-pycryptodome to python3-pycryptodomex
> - Reuse python3-pycryptodome package name to package a non compatible
> python3 module.
> 
> The rationale of this rename + reuse is that currently,
> python3-pycryptodome contains, in fact, the pycryptodomex module. So
> renaming that one + introduce the new package for the pycryptodome module.

According to apt-file(1), python3-pycryptodome contains
/usr/lib/python3/dist-packages/Cryptodome, which you use via "import
Cryptodome". If you're renaming packages anyway, would it be better for
the package containing /usr/lib/python3/dist-packages/Cryptodome to be
the python3-cryptodome package?

(My reasoning is that the name you import is the name of the "ABI",
the same way the ABI of, for example, libdbus is represented by its
SONAME libdbus-1.so.3, which we translate into libdbus-1-3 as a Debian
package name.)

> I already though of a solution on 886291 at bugs.debian.org use multiple
> dependencies with "|" but the package must still be buildable with the
> first dependency (sbuild ignore dependencies after "|" for example)

It's OK for packages in unstable to be uninstallable or unbuildable for
a short time, as long as Depends/Breaks/Conflicts or RC bugs ensure that
the brokenness doesn't propagate into testing.

For instance, if you are going ahead with your renaming plan, you could
give the new packages a versioned Breaks on python3-httpsig (<< H) and
python3-pysnmp4 (<< S), where H is the first version of python3-httpsig
that has been modified to use/expect the new (py)cryptodome(x) package
layout, and S is the corresponding version of python3-pysnmp4.

    smcv