Upload request: psrecord (NEW)

[Peter Wienemann]

Hi Alexandru,

I'd like to request an upload of the psrecord NEW package
( https://salsa.debian.org/python-team/packages/python-psrecord ) as I
don't have uploading rights. This closes #1075810. It's lintian OK and
the latest upstream version.

thanks for working on this new package. I reviewed your work and have
the following remarks:

Package name
============
I saw that you started with psrecord as source package name and tijuca
suggested to use python-psrecord in [0]. After looking into the package,
my personal preference is to switch back to psrecord as source package
name since in my view the main task of the package is to provide a
psrecord executable and I consider the fact that it is written in Python
an implementation detail. This is basically the situation mentioned by
stefanor in [1]. Therefore my proposal is to use psrecord for both the
source and the binary package name.

I understand that this is an unfortunate situation for you since one
person suggests to do A and another person suggests to do B. Therefore I
propose to wait a bit and see what other people think about this. More
opinions are much appreciated - in particular in view of recent
discussions about namespacing Python packages.

Packaging details
=================

branch layout
-------------
The team policy specifies branch name conventions [2]. According to this
policy the branch containing the upstream source should be called
"upstream". Actually used is "upstream/latest" (also note that the
presently used upstream branch does not match the branch specified in
d/gbp.conf).

d/control
---------
a) The present code fails to build in a clean build environment because
the following build dependencies are missing:
- python3-psutil
- help2man

b) The "Provides" field should be removed (cf. [3]).

d/rules
-------
a) The override_dh_auto_build target is unnecessary and can be removed.

b) The "ifeq ($(filter nodoc,$(DEB_BUILD_PROFILES)),)" block is empty
and can thus be removed.

c) When using the package clean-up validation as described on [4], I get
the following diff

1c1
< /<<PKGBUILDDIR>> directory 300
---

/<<PKGBUILDDIR>> directory 320

31a32

/<<PKGBUILDDIR>>/psrecord.egg-info directory 40

Fixing this requires replacing

rm -rf psrecord.egg-info/SOURCES.txt

by

rm -rf psrecord.egg-info

in the override_dh_auto_clean target.

d) execute_before_dh_installman target:
This assumes that the package being built is installed in the build
environment (uses /usr/bin/psrecord). What would work is using
"$(CURDIR)/debian/psrecord/usr/bin/psrecord" instead. But this requires
PYTHONPATH to be set properly, e. g. by adding

export PYTHONPATH=$(shell pybuild --print build_dir -i python3)

It is also nicer and less error-prone to avoid a hardcoded version in
the help2man call. You can set it at runtime, e. g. by adding

VERSION=$(shell dpkg-parsechangelog -S version)

and use the VERSION variable in the help2man version string.

e) If you generate the manpage during the build, it is better to remove
the static version from d/psrecord.1. Otherwise potential future changes
between the provided and the generated version will again result in
package clean-up validation issues.

d/copyright
-----------
a) According to [5], the Upstream-Contact "[m]ay be free-form text, but
by convention will usually be written as a list of RFC5322 addresses or
URIs." Following this convention means using

Upstream-Contact: Thomas Robitaille <***@gmail.com>

(note the angle brackets).

b) I see slight deviations from the upstream license file for the
"Files: *" stanza. It should be:

Copyright: 2013, Thomas P. Robitaille

In the "License: BSD-2-clause" stanza, the "All rights reserved." line
is missing.

c) There is no "Files: debian/*" stanza.

[0] https://lists.debian.org/debian-python/2024/08/msg00049.html
[1] https://lists.debian.org/debian-python/2024/10/msg00093.html
[2]
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#branch-names
[3]
https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides
[4] https://wiki.debian.org/sbuild#Validate_package_cleanup
[5] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0

Also, to anyone with admin powers, please nuke
https://salsa.debian.org/python-team/packages/psrecord as this was
migrated to the new location following discussions about naming
conventions. it's empty.

I cannot help with this part. But in view of the open discussion about
the package name, it might be prudent to wait until this issue has been
settled.

If you have questions concerning anything mentioned above, do not
hesitate to ask.

Best regards,

Peter

[Scott Kitterman]

Post by Peter Wienemann
Package name
============
I saw that you started with psrecord as source package name and tijuca
suggested to use python-psrecord in [0]. After looking into the package,
my personal preference is to switch back to psrecord as source package
name since in my view the main task of the package is to provide a
psrecord executable and I consider the fact that it is written in Python
an implementation detail. This is basically the situation mentioned by
stefanor in [1]. Therefore my proposal is to use psrecord for both the
source and the binary package name.
I understand that this is an unfortunate situation for you since one
person suggests to do A and another person suggests to do B.
Therefore I
propose to wait a bit and see what other people think about this. More
opinions are much appreciated - in particular in view of recent
discussions about namespacing Python packages.

Yes, indeed after first reading DPT conventions, I also concluded the
best source/binary pkg name combo would be plain psrecord. I'll wait a
bit more, suggestions are very much welcome. If nothing relevant
happens in the meantime (both in this thread or more general
discussions) I will move the whole repo again to salsa/dpt/psrecord.
This little tool is quite useful and I'd hate for it to be stuck in
limbo for too long.

Some additional background on this:

In the before times, what is now the Debian Python Team was two teams:

Debian Python Modules Team (DPMT)
Python Applications Packaging Team (PAPT).

DPMT packaged Python modules and extensions and the binary package naming
rules (that are at least informally extended to source package names now)
applied.

PAPT packaged applications written in Python and these naming rules did not
apply.

Part of the reason why they were separate is that there are some things about
packaging applications that are different. This is one of them. It is an
unfortunate side effect of the team's merger that this distinction has been
somewhat lost.

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.

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.

It would be good if you would review the existing DPT documentation
(particularly the policy) with this in mind and see if you have suggestions to
make it clearer.

Scott K

[Peter Wienemann]

Hi Scott,

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.

Best regards,

Peter

[0] https://peps.python.org/pep-0008/#public-and-internal-interfaces

[Peter Wienemann]

Hi Scott,

Post by Peter Wienemann

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

[Scott Kitterman]

Post by Peter Wienemann
Hi Scott,

Post by Peter Wienemann

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.

- psrecord as source package name
- python3-psrecord as binary package name (shipping executable and module)
- 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?

I think this is fine:

- psrecord as source package name
- python3-psrecord as binary package name

You can also have

Provides: psrecord

Then apt install psrecord will work.

Scott K

[Alexandru Mihail]

First, thank you all for the insightful replies !

Post by Peter Wienemann
- psrecord as source package name
- python3-psrecord as binary package name (shipping executable and module)
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?

My question towards myself, exactly. Looking forward to more opinions. Perhaps, after we decided, we (I) could update DPT docs with a nifty little table who could help others finding themselves in this niché or similar.

Post by Peter Wienemann
Best regards
Peter

Have a great one,
Alex

[Peter Wienemann]

Hi Alexandru,

Post by Peter Wienemann
d/control
---------
a) The present code fails to build in a clean build environment because
- python3-psutil
- help2man
b) The "Provides" field should be removed (cf. [3]).

I forgot one more item in the above list:

c) To be able to use the --plot option, python3-matplotlib is needed.
Therefore you should add a corresponding Recommends or Suggests field
(cf. [0]) to the binary package.

Best regards

Peter

[0]
https://www.debian.org/doc/debian-policy/ch-relationships.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends

[Peter Wienemann]

Hi Alexandru,

Post by Peter Wienemann
d/control

Done

at present both the source package and the binary package are called
"psrecord". Looking at [0] my understanding is that the recent package
name discussion concluded with

source package name: psrecord
binary package name: python3-psrecord

Please correct me if I overlooked something.

Somewhat related: I still feel uncertain what is the best matching
section for this package: "devel", "utils" or "python" (cf. [1])? I
leave the decision to you.

[0] https://lists.debian.org/debian-python/2024/10/msg00104.html
[1] https://packages.debian.org/unstable/

Post by Peter Wienemann
d/copyright
-----------

Done

Post by Peter Wienemann
In the "License: BSD-2-clause" stanza, the "All rights reserved." line
is missing.

I reread the BSD license, and what other packages have in copyright.. I
can't find the line you're talking about, could you tell me where the
line should be ?

I am referring to this line:

https://salsa.debian.org/python-team/packages/psrecord/-/blob/471390a544f149afcaa20cf1cad5c9f92c95c744/LICENSE#L2

I feel I'm getting close to upload ready for this, any extra comments
from anyone would be welcome ! If nothing else comes up, I'm going
forward and requesting an upload from anyone who has the time to do so.

Trying to build the package using the present repository contents, I get
a build failure:

$ gbp buildpackage
[...]
gbp:error: Cannot find pristine tar commit for archive
'psrecord_1.4.orig.tar.gz'
$ pristine-tar list
python-psrecord_1.4.orig.tar.gz

(BTW, I'm stuck with the main [default] branch on the psrecord repo, I
still can't figure out how to unprotect it and delete ( I think someone
with admin powers has to do that, it's been discussed here before )

I changed the default branch to "debian/master" and protected it. I
guess you should be able to delete the "main" branch now.

Best regards,

Peter

[Yaroslav Halchenko]

Thanks for this! psrecord sounds really similar to our
https://github.com/con/duct which we recently also uploaded to Debian
(it is that popular topic I guess ;) ).
https://packages.debian.org/sid/con-duct .

psrecord though is much more mature -- seems have been there for a
decade so must have more users.

Cheers!

Hello,
I'd like to request an upload of the psrecord NEW package
( https://salsa.debian.org/python-team/packages/python-psrecord ) as I
don't have uploading rights. This closes #1075810. It's lintian OK and
the latest upstream version.
Also, to anyone with admin powers, please nuke
https://salsa.debian.org/python-team/packages/psrecord as this was
migrated to the new location following discussions about naming
conventions. it's empty.
Have a great one,
Alexandru Mihail

[Peter Wienemann]

Hi Alexandru,

After implementing welcomed suggestions from people who replied to this
thread (thanks Peter et al) I think this package is ready for upload
(or further review if you find anything wrong, of course). It's lintian
https://salsa.debian.org/python-team/packages/psrecord

it seems that you forgot to push your changes to salsa. The newest
commit I see in the above repository is from November 10, 2024, i. e. it
is older than my last comments (see [0]).

Best regards

Peter

[0] https://lists.debian.org/debian-python/2024/11/msg00014.html