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
Attachment:
signature.asc
Description: This is a digitally signed message part.