Soren Stoutner <soren@debian.org> writes: >>On Saturday, November 8, 2025 5:59:27 PM Mountain Standard Time Bastian Blank >>wrote: >> On Sat, Nov 08, 2025 at 02:36:15PM -0700, Soren Stoutner wrote: >> > On Saturday, November 8, 2025 2:00:11 PM Mountain Standard Time Bastian >> > Blank >> > >> > 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 both >> > packages. >> Please read our FAQ, it is listed under "Package split". >> https://ftp-master.debian.org/REJECT-FAQ.html >> >> Such one file packages are explicitly mentioned as usually not okay to >> be split away. > > I am curious to get the team’s reaction to this. As far as I can tell, this > represents a change in expectations from the FTP Masters. It is true that > this is part of the FAQ, but there is long-standing practice of splitting such > packages to maintain the Python naming conventions. Or, am I somehow mistaken > about how it is expected that Python modules be packaged? Convention != 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
Attachment:
signature.asc
Description: PGP signature