[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Thursday, November 13, 2025 9:11:10 AM Mountain Standard Time Matthias 
Klose wrote:
> 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.

I can see that being an important concern, and I can see that being a 
persuasive reason to split the packages.

I should note that in the case of python-keepkey, “M-A: same” concerns 
probably don’t apply.  The current keepkeyctl package ships one executable to 
/usr/bin, but it is not a *compiled* executable.  Rather, it is a Python 
script that can be used as a front-end for python3-keepkey.

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

The only other file of substance that is shipped in keepkeycli is the man 
page.

Based on the conversation so far, it appears that my understanding was 
incorrect and there is no general objection to shipping files in /usr/bin 
inside of python3-foo packages as long as they do not prevent the package from 
being “M-A: same”.  I will probably wait a few more days to make sure everyone 
who might have an objection has time to comment.  But, if no other concerns 
are raised, then I plan to resubmit the package to NEW with everything 
shipping inside of python3-keepkey.

-- 
Soren Stoutner
soren@debian.org

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: