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

[Removed some unneeded participants]

Am 09.11.25 um 05:49 schrieb Soren Stoutner:
> I apologize if I did not make it clear from the original email.
> They do not, in fact, depend on each other.

Difficult to "proof" as there is no pointing to any packaging source.

> 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).

Yeah, that is basically always true no matter which Python library you 
use for an example. But also true for classical binary based libraries.

> 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.

Then your understanding is based on false assumptions, it's rather the 
normal case that most of the Python packages are a combination of a 
Python library together with executable Python scripts shipped in 
/usr/[s]bin.
And that makes sense, or in other words it makes no sense for a user 
convenience and experience to split them more. Even "your" upstream 
package (and the majority of other projects) is doing this and I see no 
good reason to divide here.

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.

> 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.

My impression is that isn't a problem in the DPT, have a look at the DPT 
maintainer overview and look into thousands listed package there. Get a 
feeling how the situation really is. I would be surprised if long time 
team members wouldn't have raise this topic as an issue before.