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.
--
Regards
Carsten
Reply to: