Hello Soren,
Am 04.10.24 um 18:41 schrieb Soren Stoutner:
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.
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-names
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.
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.
I don't think upstream needs to address here anything, they can use
whatever name for their packages.
There are more packages out there that have similar situation. I mostly
look with glasses of a user on this and will use the
python3-$(upstream-package-name) for the binary package name.
Doing a renaming isn't gaining anything here, we would need to ship
transitional packages for at least one release, create a lot work which
will not solve real problems.
I think we have other packages in the archive that could get some time
and love instead.
--
Regards
Carsten
