Path: csiph.com!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Soren Stoutner Newsgroups: linux.debian.maint.python Subject: Re: python-keepkey_7.2.1+dfsg-1_amd64.changes REJECTED Date: Sun, 09 Nov 2025 05:20:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Sun Nov 9 04:17:50 2025 Old-Return-Path: X-Amavis-Spam-Status: No, score=-7.098 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FOURLA=0.1, LDO_WHITELIST=-5, 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: -4.6 X-Greylist: delayed 1661 seconds by postgrey-1.36 at bendel; Sun, 09 Nov 2025 04:17:33 UTC User-Agent: Thunderbird for Android MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/23331 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/E8BB2D46-0D16-45F6-BE05-07A16052CA11@stoutner.com Approved: robomod@news.nic.it Lines: 96 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: Manuel Guerra , Bastian Blank X-Original-Date: Sat, 08 Nov 2025 20:49:48 -0700 X-Original-Message-ID: X-Original-References: <8605652.T7Z3S40VBb@soren-laptop> <10370999.Qv0yOoSAZ5@soren-desktop> <871pm7j3ls.fsf@gmail.com> Xref: csiph.com linux.debian.maint.python:17131 I apologize if I did not make it clear from the original email=2E They do = not, in fact, depend on each other=2E Rather, there is a pure Python modul= e 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 instal= led in /usr/bin=2E The Python module does not depend on the executable uti= lity, but the executable utility does depend on the Python module (a one-wa= y dependency, not a two-way dependency on each other)=2E If these two packages were merged, it would result in a python3-foo packag= e installing an executable in /usr/bin=2E My understanding is that is not = the Debian convention, and python3-foo packages should only install Python = modules=2E However, if my understanding is incorrect, then I don=E2=80=99t= have any problem combining them into one binary package=2E I ask the team because there are dozens or perhaps hundreds of team mainta= ined packages that follow this convention (not installing executables in py= thon3-foo binary packages, but shipping a separate, small binary package ju= st for those executables)=2E If, indeed, we need to combine them all into = single binary packages it would be important for the team to be aware of th= at=2E P=2ES=2E Please pardon the top post as I am responding on a cell phone=2E On November 8, 2025 8:18:23 PM MST, Nicholas D Steeves = wrote: >Soren Stoutner writes: > >>>On Saturday, November 8, 2025 5:59:27=E2=80=AFPM Mountain Standard Time= Bastian Blank=20 >>>wrote: >>> On Sat, Nov 08, 2025 at 02:36:15PM -0700, Soren Stoutner wrote: >>> > On Saturday, November 8, 2025 2:00:11=E2=80=AFPM Mountain Standard T= ime Bastian >>> > Blank >>> >=20 >>> > wrote: >>> > > Please merge the two binary packages=2E There is no visible reaso= n to >>> > > split them, as they depend on each other and are small=2E > >"They depend on each other" is the key point here=2E > >>> > The executables depend on the pure Python modules, but the pure Pyth= on >>> > modules do not depends on the executables (as is the case here)=2E = 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=2E >>> Please read our FAQ, it is listed under "Package split"=2E >>> https://ftp-master=2Edebian=2Eorg/REJECT-FAQ=2Ehtml >>>=20 >>> Such one file packages are explicitly mentioned as usually not okay to >>> be split away=2E >> >> I am curious to get the team=E2=80=99s reaction to this=2E As far as I= can tell, this=20 >> represents a change in expectations from the FTP Masters=2E It is true= that=20 >> this is part of the FAQ, but there is long-standing practice of splitti= ng such=20 >> packages to maintain the Python naming conventions=2E Or, am I somehow= mistaken=20 >> about how it is expected that Python modules be packaged? > >Convention !=3D policy=2E We have a convention that must be balanced agai= nst >ftpmasters policy=2E 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=2E > >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=2E "They depend on each >other" indicates that the lib isn't useful on its own=2E > >Ftpmasters' decision today doesn't mean that at some point in the future >the package shouldn't be split=2E 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=2E Why is that unacceptable? > >Cheers, >Nicholas --=20 Soren Stoutner 623-262-6169 soren@stoutner=2Ecom