Path: csiph.com!news.samoylyk.net!gothmog.csi.it!bofh.it!news.nic.it!robomod From: Scott Kitterman Newsgroups: linux.debian.maint.python Subject: Re: Upload request: psrecord (NEW) Date: Sun, 27 Oct 2024 22:20:01 +0100 Message-ID: References: X-Original-To: debian-python@lists.debian.org X-Mailbox-Line: From debian-python-request@lists.debian.org Sun Oct 27 21:19:35 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-9.5 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, LDO_WHITELIST=-5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailing-List: archive/latest/22476 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/7F8E0F01-78F5-4BEE-8314-0D9C72E92375@kitterman.com Approved: robomod@news.nic.it Lines: 67 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Sun, 27 Oct 2024 21:18:46 +0000 X-Original-Message-ID: <7F8E0F01-78F5-4BEE-8314-0D9C72E92375@kitterman.com> X-Original-References: <059e32a6-6909-48e9-aeb9-22cd31013db8@debian.org> <6029701.OdEgEQYsGK@zini-1880> <87996777-6c4e-4557-bc70-6a9b5f9977ea@debian.org> Xref: csiph.com linux.debian.maint.python:16406 On October 27, 2024 9:04:41 PM UTC, Peter Wienemann w= rote: >Hi Scott, > >On 2024-10-27 20:12:28, Peter Wienemann wrote: >> On 2024-10-26 17:00:18, Scott Kitterman wrote: >>> From reading this thread, it seems like psrecord is an application wri= tten in Python=2E=C2=A0 Upstream could, if they felt like it, re-implement = the whole thing in >>> Rust and it would still be psrecord=2E=C2=A0 Assuming that's at least = generally >>> correct, I think psrecord is definitely the correct package name=2E >>=20 >> yes, I think this applies to psrecord=2E >>=20 >>> The only exception is that applications which provide a publically ava= ilable >>> module/ extension that other programs can use should provide a binary = which >>> uses the python3-foo naming convention (see spf-engine as an example)= =2E=C2=A0 It is >>> a matter of taste and judgement for small applications that provide a = public >>> module/extension should ship the application in a separate binary pack= age or >>> not=2E=C2=A0 Generally, tiny packages are bad because they require mor= e overhead, >>> including making the packages file bigger for every single user=2E >>=20 >> In addition psrecord provides a public module (as per [0]) but I am inc= lined to consider this one of the "small application" cases which do not wa= rrant a separate binary package=2E > >re-reading your message, I think I got it wrong in my above reply=2E Sorr= y for the confusion=2E I am trying to summarize to clarify the situation: > >Since psrecord ships both an executable and a public module (and it is sm= all), the suggested package names are: > >- psrecord as source package name >- python3-psrecord as binary package name (shipping executable and module= ) > >Alternative (but not recommended due to the smallness): > >- psrecord as source package name >- python3-psrecord as binary package name (shipping the module) >- psrecord as additional binary package name (shipping the executable)=2E > >Is choosing psrecord as source package name still advisable in the above = cases? Or is python-psrecord as source package name better for the executab= le+module case? I think this is fine: - psrecord as source package name - python3-psrecord as binary package name=20 You can also have Provides: psrecord Then apt install psrecord will work=2E Scott K