Bug#998151: python-trezor: incorrect binary package name, python3-trezor should be python3-trezorlib

[Soren Stoutner]

Sandro,

I have just taken over maintenance of python-trezor and would like to rectify
this problem. As I have never renamed a python binary package, I would like
to make sure I handle it correctly.

I can see the package is indeed installed into /usr/lib/python3/dist-packages/
trezorlib, which appears to be inline with the upstream source code (/src/
trezorlib).

I assume that fixing this involves changing the name of the binary package from
“python3-trezor” to “python3-trezorlib”.

Should the other binary package be renamed from “trezor” to “trezorlib”?
Should the source package be renamed from “python-trezor” to “python-
trezorlib”? On PyPI it is named “trezor” and says it contains “trezorlib”.

https://pypi.org/project/trezor/

I assume that I need to declare a breaks/replaces on python3-trezor. Do I
need to do anything else to make the transition go smoothly?

Do I need to change any of the instances of “trezor” in debian/rules?

https://salsa.debian.org/python-team/packages/python-trezor/-/blob/debian/
master/debian/rules?ref_type=heads

Do I need to change the name of any of the files in debian/ that begin with
trezor?

https://salsa.debian.org/python-team/packages/python-trezor/-/tree/debian/
master/debian?ref_type=heads

Thanks for your help,

Soren

[Soren Stoutner]

Carsten,

Post by Soren Stoutner
Sandro,
I have just taken over maintenance of python-trezor and would like to rectify
this problem. As I have never renamed a python binary package, I would like
to make sure I handle it correctly.
I can see the package is indeed installed into
/usr/lib/python3/dist-packages/ trezorlib, which appears to be inline with
the upstream source code (/src/ trezorlib).
I assume that fixing this involves changing the name of the binary package
from “python3-trezor” to “python3-trezorlib”.

why do you think this is needed?
I don't see any reason to do so. Keep it as it is.

When I adopted this package, there was an existing bug report [1] claiming
that the existing binary package name needs to be changed to comply with
Python Policy. The bug report doesn’t explain exactly what aspect doesn’t
comply with the policy, but I assume it comes down to python3-trezor
installing to the following two directories, which have disparate names:

/usr/lib/python3/dist-packages/trezorlib/
/usr/lib/python3/dist-packages/trezor-0.13.9.egg-info/

If this isn’t a policy violation I am in favor of leaving the package name as
is, which is why I copied my response to the debian-python list.

Upstream is using the name 'trezor' as package name and we should not
derive from that if not really strong reasons are given to do this.
Again I even don't see any more light reasons to do this renaming.

Upstream seems to use both trezor and trezorlib, with the PyPI package named
trezor while the files are installed to trezorlib. Perhaps that is a problem
that upstream should address. I would appreciate any guidance on the best way
to proceed with the Debian packaging.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998151

[Simon McVittie]

The bug report doesn’t explain exactly what aspect doesn’t
comply with the policy, but I assume it comes down to python3-trezor
/usr/lib/python3/dist-packages/trezorlib/
/usr/lib/python3/dist-packages/trezor-0.13.9.egg-info/

Yes, it's somewhat common for the PyPI distribution name (trezor) and
the importable module name (trezorlib) to be different. Unfortunately,
both of those names are part of the API, and both have a reasonable
claim to be "the" name of the library.

https://www.debian.org/doc/packaging-manuals/python-policy/index.html#module-package-names
says that the Debian Python team's policy is that the name that matters,
for the purposes of our naming convention, is the name that you can
`import`. python3-dbus and python3-xdg are some good examples of
packages where the name you can `import` does not match the PyPI name,
and the Debian package has been named according to our policy.

This is similar to Debian's policy that the package containing a C/C++
library with a SONAME like "libgtk-4.so.1" should be "libgtk-4-1",
even if the upstream developer would usually refer to it as something
more like "GTK 4" or "gtk-4".

Like the C/C++ library naming policy, this is a "should" and not a "must",
so the decision for you to make as maintainer is whether the disruption
of renaming to python3-trezorlib is sufficient to justify this package
being an exception to the policy. If yes, mark the bug wontfix; if no,
do the rename.

(Compare with the C library "libsdl1.2debian", which should have been named
libsdl-1.2-0 according to the systematic naming scheme in Policy, but
wasn't, and we have kept its original name because the disruption that
would be caused by renaming it seems greater than the benefit.)

smcv

[Soren Stoutner]

Control: tags -1 moreinfo

Carsten,

the Python policy hasn't got updates and adjustments since years, a lot
of things are a bit outdated e.g. how to handle Python2 based packages.
The part Sandro was referring to is §4.3
https://www.debian.org/doc/packaging-manuals/python-policy/#module-package-nam
es
This isn't a rule of MUST, it's SHOULD and this is good. I think this
package is a good example why.
User will not search for python3-trezorlib because the upstream name is
trezor. The module name is basically important for programmers because
they need to know which module they need to use and therefore include.

Thank you for the detailed explanation. I am inclined to follow your advice
and leave the package names as is.

Sandro,

As you were the original filer of the bug, I want to give you a chance to
respond if you still feel that renaming the binary package is appropriate. If
I don’t hear from you in a reasonable amount of time I will close the bug
report.