Path: csiph.com!weretis.net!feeder8.news.weretis.net!fu-berlin.de!bofh.it!news.nic.it!robomod From: Matthias Klose Newsgroups: linux.debian.maint.python Subject: Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Date: Thu, 13 Nov 2025 17:20:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Thu Nov 13 16:11:31 2025 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.597 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, KHOP_HELO_FCRDNS=0.399, LDO_WHITELIST=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -2.7 Old-X-Envelope-From: doko@debian.org Old-X-Envelope-To: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailing-List: archive/latest/23351 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/ed4cc729-dd48-4234-a68a-ab2ccef82f52@debian.org Approved: robomod@news.nic.it Lines: 33 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Thu, 13 Nov 2025 17:11:10 +0100 X-Original-Message-ID: X-Original-References: <8605652.T7Z3S40VBb@soren-laptop> <10370999.Qv0yOoSAZ5@soren-desktop> <871pm7j3ls.fsf@gmail.com> <7656f4eb-4dd5-4bdb-9bda-a2a055fedf3c@t-online.de> Xref: csiph.com linux.debian.maint.python:17148 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