Path: csiph.com!goblin2!goblin1!goblin.stu.neva.ru!fu-berlin.de!bofh.it!news.nic.it!robomod From: Barry Warsaw Newsgroups: linux.debian.maint.python Subject: Bug #751908, tox, and bin-only Python packages Date: Thu, 06 Aug 2015 17:00:02 +0200 Message-ID: X-Original-To: Old-Return-Path: X-Amavis-Spam-Status: No, score=-12 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, LDO_WHITELIST=-5, PGPSIGNATURE=-5] autolearn=ham X-Policyd-Weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_BL_NJABL=-1.5 CL_IP_EQ_HELO_IP=-2 (check from: .debian. - helo: .mail.wooz. - helo-domain: .wooz.) FROM/MX_MATCHES_NOT_HELO(DOMAIN)=0; rate: -5 X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/OEJPs=m91_S2vQ42b+Y5o8U"; protocol="application/pgp-signature" X-Mailing-List: archive/latest/12451 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 90 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Thu, 6 Aug 2015 10:50:51 -0400 X-Original-Message-ID: <20150806105051.3617b186@limelight.wooz.org> Xref: csiph.com linux.debian.maint.python:7146 --Sig_/OEJPs=m91_S2vQ42b+Y5o8U Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable 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 librari= es, 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 stron= gly 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. 'f= oo' 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 --Sig_/OEJPs=m91_S2vQ42b+Y5o8U Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVw3RLAAoJEBJutWOnSwa/KtUP/3n/DstLNeJEjotcDDmYKDRt K1MTVAme6XHKmPJfKSo0Aq81P7JC1bndmNVhswsn3yxKvY0/BCB4Yk3GxRhXNDA+ HmePp6I0q771xTHi4AdbKXS/ttAuEM9pc5vCulD4roGgg21UgmAd8tqfjaSWW90Y ioFLgxoLDn78PdAE6rUu4Yv8eErUuMmIt7X60ZBgI6bWhYt6AYItK7bwrosLe1fI HxHbFqWhry+KA4Z8A0Ud8Xu5g/M0LJ1xaOh7GTXMOKcausQs1HeDujaAHgynKxUN WcV/LllWoavm6VcWAYfjx/MV75CeyojF73BqFFJJU/HAvMUKEs9JgjjeW2qpbJoG yfn5cfMmfqFnhqMktcgXqCboKC/9TZIDmAMjKCPeYmOhMFdhzjktnwxzUwCFLwqZ H5wHH0N6+VlrWvfd2IXGeDunVuTdaSy1MN0xrLs9mz4ozIU1dDaPlVzjt7YSnP18 E4Qd3pwXC0CgmKtIkeBsVedLmFpxnNo3pqIOUlv4nM2J5Bwn6zNRy+e5IhAM5XVp rPu7YODhNHsl+zJeOEOB6qZJjIGxi+D1uA1wbl/kepP/nk/CSh4Z0GStDqMUGuG5 9POG0T2Xv8D6wOe0uFZ9aKOJBpgAGcA6PseHYJhZowriqpRqJOQweSxLkq3MOfqJ erMLIGoRuLZpwxjhbSdZ =jCPg -----END PGP SIGNATURE----- --Sig_/OEJPs=m91_S2vQ42b+Y5o8U-- -- To UNSUBSCRIBE, email to debian-python-REQUEST@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org Archive: https://lists.debian.org/20150806105051.3617b186@limelight.wooz.org