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

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

Re: Upload request: psrecord (NEW)

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: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-10-24 21:40 +0200
    Re: Upload request: psrecord (NEW) Scott Kitterman <debian@kitterman.com> - 2024-10-26 17:10 +0200
      Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-10-27 20:20 +0100
        Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-10-27 22:10 +0100
          Re: Upload request: psrecord (NEW) Scott Kitterman <debian@kitterman.com> - 2024-10-27 22:20 +0100
          Re: Upload request: psrecord (NEW) Alexandru Mihail <alexandru.mihail2897@gmail.com> - 2024-10-27 22:30 +0100
    Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-10-27 20:50 +0100
    Re: Upload request: psrecord (NEW) Peter Wienemann <wiene@debian.org> - 2024-11-11 20:20 +0100

#16400 — Re: Upload request: psrecord (NEW)

Hi Alexandru,

On 2024-10-15 18:02:10, Alexandru Mihail wrote:
> 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 <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

[toc] | [next] | [standalone]

#16402

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

On Saturday, October 26, 2024 7:26:48 AM EDT Alexandru Mihail wrote:
> > 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

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

#16403

Hi Scott,

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.

Best regards,

Peter

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

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

#16405

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

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

#16406

On October 27, 2024 9:04:41 PM UTC, Peter Wienemann <wiene@debian.org> wrote:
>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?

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

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

#16407

First, thank you all for the insightful replies ! 
> - 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.
> Best regards
> 
> Peter
> 
Have a great one,
Alex

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

#16404

Hi Alexandru,

On 2024-10-24 21:30:48, Peter Wienemann wrote:
> 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]).

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

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

#16443

Hi Alexandru,

On 2024-11-10 19:23:29, Alexandru Mihail wrote:
>> 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/

>> d/copyright
>> -----------
> Done
>>
>> 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

[toc] | [prev] | [standalone]

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

csiph-web