Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #17134

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

Show key headers only | View raw

[Multipart message — attachments visible in raw view] - view raw

On Saturday, November 8, 2025 11:33:21 PM Mountain Standard Time Carsten 
Schoenert wrote:
> [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.

Here is the package source:

https://salsa.debian.org/python-team/packages/python-keepkey


On Sunday, November 9, 2025 5:07:30 AM Mountain Standard Time Bastian Blank 
wrote:
> On Sat, Nov 08, 2025 at 08:49:48PM -0700, Soren Stoutner wrote:
> > 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).
> They do:
> | Package: keepkeyctl
> | Source: python-keepkey
> | Depends: python3:any, python3-keepkey (= 7.2.1+dfsg-1)

*One* of the packages depends on the other.  Perhaps we are misunderstanding 
each other, but that is different than *both* packages depending on each 
other.

https://salsa.debian.org/python-team/packages/python-keepkey/-/blob/debian/
master/debian/control?ref_type=heads


On Saturday, November 8, 2025 8:18:23 PM Mountain Standard Time Nicholas D 
Steeves wrote:
> 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?

What you describe in the above paragraph is already the case.  The library 
does not depend on the CLI utility and it is useful as a general system 
library.  Indeed, it is posted on PyPI.org (although the latest version hasn’t 
been posted there for some reason).

https://pypi.org/project/keepkey/


On Sunday, November 9, 2025 5:37:18 AM Mountain Standard Time Gregor Riepl 
wrote:
> 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.

Indeed.  When I originally went to answer Bastian’s question, I looked in the 
Debian Python Policy for something I could quote explaining this situation.  I 
was a little surprised not to find it explicitly described, as this has been 
the standard practice for Python packages since I have been packaging for 
Debian.  Part of the reason why I included the Python team in this discussion 
is to understand if I have been misinformed about the Python packaging 
expectations.  If so, there are a lot of our team maintained packages that 
need to be updated.

When the package was initially rejected, the stated reason was because both of 
the binary package depended on each other.  If that had been the case, I would 
have agreed.  But, as demonstrated in the link above, they do not both depend 
on each other.

When I responded explaining that they did not both depend on each other, and 
that for Python libraries, it is customary for the library to be in one 
package and any executable utilities in a separate package, the response was 
that they should still be merged into one binary package because they were 
small, with a link to the FAQ talking about how small packages should not be 
split off from each other.

>Please read our FAQ, it is listed under "Package split".
>https://ftp-master.debian.org/REJECT-FAQ.html

I wholeheartedly agree with that principle in general.  These are small 
packages, and, in this case, there is only a single executable being installed 
into /usr/bin.  However, my previous understanding was that the very different 
nature of the two binary packages (one being a system library, the other being 
an executable utility) was sufficient reason for them to be separate.

-- 
Soren Stoutner
soren@debian.org

Back to linux.debian.maint.python | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Soren Stoutner <soren@debian.org> - 2025-11-09 02:20 +0100
  Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Nicholas D Steeves <sten@debian.org> - 2025-11-09 04:20 +0100
    Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Soren Stoutner <soren@stoutner.com> - 2025-11-09 05:20 +0100
      Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Carsten Schoenert <c.schoenert@t-online.de> - 2025-11-09 07:50 +0100
        Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Soren Stoutner <soren@debian.org> - 2025-11-09 15:40 +0100
        Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Matthias Klose <doko@debian.org> - 2025-11-13 17:20 +0100
          Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Soren Stoutner <soren@debian.org> - 2025-11-13 19:10 +0100
            Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Soren Stoutner <soren@debian.org> - 2025-11-20 23:00 +0100
      Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Bastian Blank <waldi@debian.org> - 2025-11-09 13:30 +0100

csiph-web