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
written in Python. Upstream could, if they felt like it, re-implement
the whole thing in
Rust and it would still be psrecord. Assuming that's at least generally
correct, I think psrecord is definitely the correct package name.
yes, I think this applies to psrecord.
The only exception is that applications which provide a publically
available
module/ extension that other programs can use should provide a binary
which
uses the python3-foo naming convention (see spf-engine as an
example). 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
package or
not. Generally, tiny packages are bad because they require more
overhead,
including making the packages file bigger for every single user.
In addition psrecord provides a public module (as per [0]) but I am
inclined to consider this one of the "small application" cases which do
not warrant a separate binary package.
re-reading your message, I think I got it wrong in my above reply. Sorry
for the confusion. I am trying to summarize to clarify the situation:
Since psrecord ships both an executable and a public module (and it is
small), 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).
Is choosing psrecord as source package name still advisable in the above
cases? Or is python-psrecord as source package name better for the
executable+module case?
Best regards
Peter
