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

Groups > linux.debian.maint.python > #17129 > unrolled thread

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

Back to article view | Back to linux.debian.maint.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

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

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

I am resending the messages below to the Debian Python Team mailing list for 
further input.

On Saturday, November 8, 2025 2:36:15 PM Mountain Standard Time Soren Stoutner 
wrote:
> On Saturday, November 8, 2025 2:00:11 PM Mountain Standard Time Bastian
> Blank
> 
> wrote:
> > Please merge the two binary packages.  There is no visible reason to
> > split them, as they depend on each other and are small.
> 
> I am a little confused.  This package structure is what is typically used by
> the Debian Python Team.
> 
> 1.  Pure Python modules are packaged as python3-foo, are part of the python
> section, and install to /usr/lib/python3/dist-packages.
> 
> 2.  Executables are packaged separately, are part of the utils section, and
> install to /usr/bin.
> 
> The executables depend on the pure Python modules, but the pure Python
> modules
> do not depends on the executables (as is the case here).  This is because
> there are use cases where other program only need to depend on the pure
> Python modules, but a user installing the executable will want both
> packages.
> 
> There are a lot of examples of this.  Here are a few that I just pulled out,
> but there are probably dozens or hundreds of examples.
> 
> https://tracker.debian.org/pkg/electrum
> https://tracker.debian.org/pkg/alembic
> https://tracker.debian.org/pkg/beancount
> https://tracker.debian.org/pkg/cssmin
> https://tracker.debian.org/pkg/python3-dmm
> https://tracker.debian.org/pkg/flatlatex
> 
> Are you saying that the standard way the Debian Python Team has been
> packaging
> programs should be changed?

Bastian Blank responded to the above with the following:

>On Saturday, November 8, 2025 5:59:27 PM Mountain Standard Time Bastian Blank 
>wrote:
> On Sat, Nov 08, 2025 at 02:36:15PM -0700, Soren Stoutner wrote:
> > On Saturday, November 8, 2025 2:00:11 PM Mountain Standard Time Bastian
> > Blank
> > 
> > wrote:
> > > Please merge the two binary packages.  There is no visible reason to
> > > split them, as they depend on each other and are small.
> > 
> > The executables depend on the pure Python modules, but the pure Python
> > modules do not depends on the executables (as is the case here).  This is
> > because there are use cases where other program only need to depend on the
> > pure Python modules, but a user installing the executable will want both
> > packages.
> Please read our FAQ, it is listed under "Package split".
> https://ftp-master.debian.org/REJECT-FAQ.html
> 
> Such one file packages are explicitly mentioned as usually not okay to
> be split away.

I am curious to get the team’s reaction to this.  As far as I can tell, this 
represents a change in expectations from the FTP Masters.  It is true that 
this is part of the FAQ, but there is long-standing practice of splitting such 
packages to maintain the Python naming conventions.  Or, am I somehow mistaken 
about how it is expected that Python modules be packaged?

-- 
Soren Stoutner
soren@debian.org

[toc] | [next] | [standalone]

#17130

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

Soren Stoutner <soren@debian.org> writes:

>>On Saturday, November 8, 2025 5:59:27 PM Mountain Standard Time Bastian Blank 
>>wrote:
>> On Sat, Nov 08, 2025 at 02:36:15PM -0700, Soren Stoutner wrote:
>> > On Saturday, November 8, 2025 2:00:11 PM Mountain Standard Time Bastian
>> > Blank
>> > 
>> > wrote:
>> > > Please merge the two binary packages.  There is no visible reason to
>> > > split them, as they depend on each other and are small.

"They depend on each other" is the key point here.

>> > The executables depend on the pure Python modules, but the pure Python
>> > modules do not depends on the executables (as is the case here).  This is
>> > because there are use cases where other program only need to depend on the
>> > pure Python modules, but a user installing the executable will want both
>> > packages.
>> Please read our FAQ, it is listed under "Package split".
>> https://ftp-master.debian.org/REJECT-FAQ.html
>> 
>> Such one file packages are explicitly mentioned as usually not okay to
>> be split away.
>
> I am curious to get the team’s reaction to this.  As far as I can tell, this 
> represents a change in expectations from the FTP Masters.  It is true that 
> this is part of the FAQ, but there is long-standing practice of splitting such 
> packages to maintain the Python naming conventions.  Or, am I somehow mistaken 
> about how it is expected that Python modules be packaged?

Convention != policy. We have a convention that must be balanced against
ftpmasters policy.  Can you find a citation in DPT Policy that says it's
more than a convention?  I haven't looked at your specific case, but
there are precedents where the Python lib can be considered internal to
the application and/or not useful as a system lib, and there used to be
more documentation about this when the DPT had the PAPT subsection.

I would be surprised if ftpmasters were wrong in this case, and that
packaging the lib with the application (as historic PAPT packages were)
would somehow do a grave disservice to our users.  "They depend on each
other" indicates that the lib isn't useful on its own.

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?

Cheers,
Nicholas

[toc] | [prev] | [next] | [standalone]

#17131

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).

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.

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.

P.S.  Please pardon the top post as I am responding on a cell phone.


On November 8, 2025 8:18:23 PM MST, Nicholas D Steeves <sten@debian.org> wrote:
>Soren Stoutner <soren@debian.org> writes:
>
>>>On Saturday, November 8, 2025 5:59:27 PM Mountain Standard Time Bastian Blank 
>>>wrote:
>>> On Sat, Nov 08, 2025 at 02:36:15PM -0700, Soren Stoutner wrote:
>>> > On Saturday, November 8, 2025 2:00:11 PM Mountain Standard Time Bastian
>>> > Blank
>>> > 
>>> > wrote:
>>> > > Please merge the two binary packages.  There is no visible reason to
>>> > > split them, as they depend on each other and are small.
>
>"They depend on each other" is the key point here.
>
>>> > The executables depend on the pure Python modules, but the pure Python
>>> > modules do not depends on the executables (as is the case here).  This is
>>> > because there are use cases where other program only need to depend on the
>>> > pure Python modules, but a user installing the executable will want both
>>> > packages.
>>> Please read our FAQ, it is listed under "Package split".
>>> https://ftp-master.debian.org/REJECT-FAQ.html
>>> 
>>> Such one file packages are explicitly mentioned as usually not okay to
>>> be split away.
>>
>> I am curious to get the team’s reaction to this.  As far as I can tell, this 
>> represents a change in expectations from the FTP Masters.  It is true that 
>> this is part of the FAQ, but there is long-standing practice of splitting such 
>> packages to maintain the Python naming conventions.  Or, am I somehow mistaken 
>> about how it is expected that Python modules be packaged?
>
>Convention != policy. We have a convention that must be balanced against
>ftpmasters policy.  Can you find a citation in DPT Policy that says it's
>more than a convention?  I haven't looked at your specific case, but
>there are precedents where the Python lib can be considered internal to
>the application and/or not useful as a system lib, and there used to be
>more documentation about this when the DPT had the PAPT subsection.
>
>I would be surprised if ftpmasters were wrong in this case, and that
>packaging the lib with the application (as historic PAPT packages were)
>would somehow do a grave disservice to our users.  "They depend on each
>other" indicates that the lib isn't useful on its own.
>
>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?
>
>Cheers,
>Nicholas


-- 
Soren Stoutner
623-262-6169
soren@stoutner.com

[toc] | [prev] | [next] | [standalone]

#17132

[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

[toc] | [prev] | [next] | [standalone]

#17134

[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

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#17150

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

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

[toc] | [prev] | [next] | [standalone]

#17182

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

On Thursday, November 13, 2025 11:05:56 AM Mountain Standard Time Soren 
Stoutner wrote:
> 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.

I have resubmitted the package with everything shipping inside the python3-
keepkey binary package.

-- 
Soren Stoutner
soren@debian.org

[toc] | [prev] | [next] | [standalone]

#17133

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)

> 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.

And there is no problem with installing an executable along the library.

Bastian

-- 
Respect is a rational process
		-- McCoy, "The Galileo Seven", stardate 2822.3

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web