Back in June 2014, I filed bug #751908, which Piotr closed as wontfix. This is really related to an open question in Python packaging concerning a standard naming scheme for packages which provide Python applications (e.g. /usr/bin scripts) whether or not they also provide importable libraries, although it's trickier when they don't (e.g. tox).
AFAICT, Debian Python Policy is silent on this. The example that sparked issue #751908 was tox, which when I initially packaged it, I called the binary package python-tox. I did this because, while the package does not provide any publicly importable modules, I felt it was presumptuous to claim a rather generic name like 'tox' as the binary package. As it turns out, almost 3 years later there are no other claims on binary package name 'tox' in the archive, so my concern might have been unnecessary. The reason I opened the bug was because of dh_python3's behavior that the normal set of renames (e.g. usr/lib/python3.X/dist-packages to usr/lib/python3/dist-packages) isn't done for binary packages named with the python- prefix. I follow and largely agree with Piotr's reasoning for closing bug wontfix, but that still doesn't help. ;) This is biting me today as I try to fix the tox source package so that it will build in a world with two supported Python 3 versions, as is the case in Ubuntu 15.10 currently. The hack in d/rules I had been using breaks with multiple versions of Python 3. I can fix the hack, or I can rename the binary package to 'tox'. I'm strongly inclined to the latter, with either a dummy transitional package or a provides/replace/conflicts transition. I'm happy to hear your thoughts on that, but let's talk about the larger issue. Should there be a naming convention for Python packages which only provide an executable? Clearly they can't be called 'python-foo' or 'python3-foo'. We're reserving those names for binary packages that provide importable libraries of the appropriate language version. Ideally you could just claim 'foo' but there may be problems with that. 'foo' might collide with some other existing package name. In other cases, maintainers might consider it presumptuous and not very friendly to claim a generic name. What should we recommend? Do we need to recommend anything, or do we just let the maintainer decide? At the very least, DPP must proscribe using python-foo or python3-foo. Cheers, -Barry
pgpVNd4C_Bh56.pgp
Description: OpenPGP digital signature
