Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED

On 11/9/25 13:37, Gregor Riepl wrote:
>> There are only a few packages that ship a binary only binary approach 
>> in the Python corner. And if so the ecosystem is more complex. That's 
>> not the case for keepkey.
> 
> This seems quite odd to me. If a Python module contains a corresponding 
> application that is frequently used directly, I would expect this to be 
> installed in its own package, named like the application, and not in a 
> pyhon3-modulename package.
> 
> If the corresponding module is rarely, if ever used, it's probably 
> better to not produce a python3-modulename package at all, and simply 
> put the module into /usr/share/modulename - this is described in the 
> packaging policy: [1]
> 
> In fact, I can't find any guidance on combined Python module+application 
> packages (except for the mentioned case of private modules) in the 
> Debian Python Policy. If there is any, I'd be very interested as well.
> 
> [1] https://www.debian.org/doc/packaging-manuals/python-policy/ 
> #programs-shipping-private-modules

care to draft something for the Debian policy?

another reason for splitting even one binary is to have the python3-* 
package M-A: same or M-A: foreign.  This is usually required for 
extension modules very low in the dependency chain.  I didn't check if 
that's the case for this specific package.

Addressing these issues in the policy also should give ftp-masters some 
guidance.

Matthias