Path: csiph.com!weretis.net!feeder8.news.weretis.net!srl.newsdeef.eu!news.corradoroberto.it!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Nicholas D Steeves Newsgroups: linux.debian.maint.python Subject: Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Date: Sun, 09 Nov 2025 04:20:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Sun Nov 9 03:18:47 2025 Old-Return-Path: X-Amavis-Spam-Status: No, score=-114.41 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FOURLA=0.1, LDO_WHITELIST=-5, PGPSIGNATURE=-5, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, USER_IN_DKIM_WELCOMELIST=-0.01, USER_IN_DKIM_WHITELIST=-100] autolearn=ham autolearn_force=no MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Debian-User: sten X-Mailing-List: archive/latest/23330 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/871pm7j3ls.fsf@gmail.com Approved: robomod@news.nic.it Lines: 86 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Manuel Guerra , Bastian Blank X-Original-Date: Sat, 08 Nov 2025 22:18:23 -0500 X-Original-Message-ID: <871pm7j3ls.fsf@gmail.com> X-Original-References: <8605652.T7Z3S40VBb@soren-laptop> <10370999.Qv0yOoSAZ5@soren-desktop> Xref: csiph.com linux.debian.maint.python:17130 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Soren Stoutner writes: >>On Saturday, November 8, 2025 5:59:27=E2=80=AFPM Mountain Standard Time B= astian Blank=20 >>wrote: >> On Sat, Nov 08, 2025 at 02:36:15PM -0700, Soren Stoutner wrote: >> > On Saturday, November 8, 2025 2:00:11=E2=80=AFPM Mountain Standard Tim= e Bastian >> > Blank >> >=20 >> > wrote: >> > > Please merge the two binary packages. There is no visible reason to >> > > split them, as they depend on each other and are small. "They depend on each other" is the key point here. >> > The executables depend on the pure Python modules, but the pure Python >> > modules do not depends on the executables (as is the case here). This= is >> > because there are use cases where other program only need to depend on= the >> > pure Python modules, but a user installing the executable will want bo= th >> > packages. >> Please read our FAQ, it is listed under "Package split". >> https://ftp-master.debian.org/REJECT-FAQ.html >>=20 >> Such one file packages are explicitly mentioned as usually not okay to >> be split away. > > I am curious to get the team=E2=80=99s reaction to this. As far as I can= tell, this=20 > represents a change in expectations from the FTP Masters. It is true tha= t=20 > this is part of the FAQ, but there is long-standing practice of splitting= such=20 > packages to maintain the Python naming conventions. Or, am I somehow mis= taken=20 > about how it is expected that Python modules be packaged? Convention !=3D policy. We have a convention that must be balanced against ftpmasters policy. Can you find a citation in DPT Policy that says it's more than a convention? I haven't looked at your specific case, but there are precedents where the Python lib can be considered internal to the application and/or not useful as a system lib, and there used to be more documentation about this when the DPT had the PAPT subsection. I would be surprised if ftpmasters were wrong in this case, and that packaging the lib with the application (as historic PAPT packages were) would somehow do a grave disservice to our users. "They depend on each other" indicates that the lib isn't useful on its own. Ftpmasters' decision today doesn't mean that at some point in the future the package shouldn't be split. If a future version of the lib no longer depends on the app and is useful as a general system lib, then that is when you add the second package and send it through the NEW queue for reevaluation. Why is that unacceptable? Cheers, Nicholas --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJEBAEBCgAuFiEE4qYmHjkArtfNxmcIWogwR199EGEFAmkQB/8QHHN0ZW5AZGVi aWFuLm9yZwAKCRBaiDBHX30QYTzsEACfleG7up4HMyed9waNPFnEqwxw0cJGD298 Wk+5lRZfGtvx7Z23+mXAGjLR0/TvEZNV4PITtHkkkZ/CEiwVXI4IuyYpR74zF4Q/ +LAFZw+lg/Ilr/n5jqNKmojMmWwPQTimmV2P++zZm2SWcxMsInUrysc1PIBbJrRE umTmnrcR5wSy1h+QU7CgIlwi7WKwRN6QnIt4M4EiehrWx4nYVcSNoQ5LIDHWK6u6 l+bbFCuc9rlAfC+PsVZHfok6TTag2ug66qzCoYd6URIvHPhjTBPQlw/f9tcCaK9h lwi/hqIa2XybC9641DhL9qfU2pxwTlh/Mbv8Y7HhoLlwpLhyyPehRHUtERmVymBm WGJyiy7BY8MgAaSMRwUXqnHW8HVPEAr5zTpOc+SqhpKx6MmM4O9HS54zbvoH7Rc4 tBKCrmbE4PVuXCFbYYUeLFObuK0MqOn58tlmdCpnQfb0CYwbwjk09B7P/2rhbdPS sd4ARC8YYcNekLE3f31dLplNPCgMlZhfwZyRNuhFdk0k3MPsN0SgZpJmC49oG8vg Z0F3O4aAPAvk2btIXuBJ8h2pMEWoN/mmc5H0d6I/A4hoOqlAHV3FPHb7RE6f5jol l+LOEB6yFj2PvTclLXRU4tqAjNh3+f2rI6a8w8mvctUncFTtXPjb0MHNDmyUkLWh eSSWfosgAQ== =5GK5 -----END PGP SIGNATURE----- --=-=-=--