Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED
I apologize if I did not make it clear from the original email. They do not, in fact, depend on each other. Rather, there is a pure Python module that can be used by other programs (in fact, the purpose in packaging it is for Electrum to use the Python module) and an optional executable installed in /usr/bin. The Python module does not depend on the executable utility, but the executable utility does depend on the Python module (a one-way dependency, not a two-way dependency on each other).
If these two packages were merged, it would result in a python3-foo package installing an executable in /usr/bin. My understanding is that is not the Debian convention, and python3-foo packages should only install Python modules. However, if my understanding is incorrect, then I don’t have any problem combining them into one binary package.
I ask the team because there are dozens or perhaps hundreds of team maintained packages that follow this convention (not installing executables in python3-foo binary packages, but shipping a separate, small binary package just for those executables). If, indeed, we need to combine them all into single binary packages it would be important for the team to be aware of that.
P.S. Please pardon the top post as I am responding on a cell phone.
On November 8, 2025 8:18:23 PM MST, Nicholas D Steeves <sten@debian.org> wrote:
>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
--
Soren Stoutner
623-262-6169
soren@stoutner.com
Reply to: