Is there a point to retaining src:pth?

[наб]

Hi!

src:pth has been gone from testing since August.
There are no rdeps and no rbuilddeps,
and only FTBFS bugs since like 2012.
I can hardly imagine a point to Pth at all in 2024
(or any time after ubiquitous pthread support),
so it reads to me like an easy QA removal.

But, this seems incongruent with the
inst~15000 + vote~15 popcon
(admittedly, with a peak of 50k, that may just be latent).

What am I missing here? Is there any reason for any one
to install libpth{20,-dev} at any time any more?

Best,

[Ben Hutchings]

Post by наб
Hi!
src:pth has been gone from testing since August.
There are no rdeps and no rbuilddeps,
and only FTBFS bugs since like 2012.
I can hardly imagine a point to Pth at all in 2024
(or any time after ubiquitous pthread support),
so it reads to me like an easy QA removal.
But, this seems incongruent with the
inst~15000 + vote~15 popcon
(admittedly, with a peak of 50k, that may just be latent).

I'm not seeing those numbers. Maybe because pth had an ABI bump for
time64 and libpth20 is no longer on the graph.

Post by наб
What am I missing here? Is there any reason for any one
to install libpth{20,-dev} at any time any more?

GnuPG once used pth, but switched to npth over a decade ago. As
recently as bullseye, pth still had some significant reverse-
(build-)dependencies:

$ grep-dctrl -FBuild-Depends -sPackage libpth-dev /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_source_Sources
Package: gcc-9
Package: libdap
Package: pianobar
Package: unicon
Package: zhcon
$ grep-dctrl -FDepends -sPackage libpth20 /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
Package: libgm2-0
Package: genometools-common
Package: libpth-dev
Package: zhcon

but it does seem like it can be dropped now.

Ben.

[наб]

Post by Ben Hutchings

Post by наб
src:pth has been gone from testing since August.
There are no rdeps and no rbuilddeps,
and only FTBFS bugs since like 2012.
I can hardly imagine a point to Pth at all in 2024
(or any time after ubiquitous pthread support),
so it reads to me like an easy QA removal.
But, this seems incongruent with the
inst~15000 + vote~15 popcon
(admittedly, with a peak of 50k, that may just be latent).

I'm not seeing those numbers. Maybe because pth had an ABI bump for
time64 and libpth20 is no longer on the graph.

Had to dig these out of the graph manually:
https://qa.debian.org/popcon-graph.php?packages=libpth20t64+libpth20+libpth-dev&show_vote=on&show_old=on&want_legend=on&want_ticks=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
https://qa.debian.org/popcon-graph.php?packages=libpth20t64+libpth20+libpth-dev&show_vote=on&show_old=on&want_legend=on&want_ticks=on&from_date=2020-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

Post by Ben Hutchings

Post by наб
What am I missing here? Is there any reason for any one
to install libpth{20,-dev} at any time any more?

GnuPG once used pth, but switched to npth over a decade ago.

That historical context was what I was missing,
and certainly matches the peak and cliff.

Post by Ben Hutchings
As recently as bullseye, pth still had some significant

This looked like a scary prospect,

Post by Ben Hutchings
$ grep-dctrl -FBuild-Depends -sPackage libpth-dev /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_source_Sources
Package: gcc-9
Package: libdap
Package: pianobar
Package: unicon
Package: zhcon
$ grep-dctrl -FDepends -sPackage libpth20 /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
Package: libgm2-0
Package: genometools-common
Package: libpth-dev
Package: zhcon

but from the changelogs and relevant bugs,
it looks like all of these specced that by accident as a left-over.

So it was deeply vestigial even in bullseye,
and the maintainer trimmed it off most of the way.

Post by Ben Hutchings
but it does seem like it can be dropped now.

https://bugs.debian.org/1087708

Thanks,

[xiao sheng wen(肖盛文)]

在 2024/11/17 22:34, наб 写道:
[...]

Post by наб

Post by Ben Hutchings
As recently as bullseye, pth still had some significant

This looked like a scary prospect,

Post by Ben Hutchings
$ grep-dctrl -FBuild-Depends -sPackage libpth-dev /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_source_Sources
Package: gcc-9
Package: libdap
Package: pianobar
Package: unicon
Package: zhcon
$ grep-dctrl -FDepends -sPackage libpth20 /var/lib/apt/lists/deb.debian.org_debian_dists_bullseye_main_binary-amd64_Packages
Package: libgm2-0
Package: genometools-common
Package: libpth-dev
Package: zhcon

zhcon is team maintained by Debian Chinese Team
<chinese-***@lists.alioth.debian.org>, I'm one of Uploaders.
zhcon not use libpth-dev from zhcon (1:0.2.6-19):
https://sources.debian.org/src/zhcon/1%3A0.2.6-20/debian/changelog/#L27

The team maintained package unicon also use libpth-dev before, the
maintainer of libpth NIIBE Yutaka <***@debian.org> had send the patch
for remove libpth-dev in package unicon.

https://salsa.debian.org/chinese-team/unicon/-/merge_requests/1/commits

Post by наб
but from the changelogs and relevant bugs,
it looks like all of these specced that by accident as a left-over.
So it was deeply vestigial even in bullseye,
and the maintainer trimmed it off most of the way.

Post by Ben Hutchings
but it does seem like it can be dropped now.

https://bugs.debian.org/1087708

The maintainer of pth NIIBE Yutaka <***@debian.org> is active.
I'd meet him in Debconf24 Busan.

Why not let NIIBE do this RM report by himself?


Regards,

[NIIBE Yutaka]

Hello,

Xiao Shen Wen, thank you for including me in the loop. I noticed that
the removal by the 1087708. And, thanks to nabijaczleweli for the
action of removing the package.

Removing GNU Pth package in Debian is good. That's good move and I
support this decision. In Debian, you know, I have been trying to
decrease the number of packages which depend on pth, so that pth could
be removed. The final move was done, not by me, but I don't care.
Right Thing can be done by anyone.

Post by xiao sheng wen(肖盛文)
Why not let NIIBE do this RM report by himself?

Well, perhaps, that's because I was lazy and/or too conservative for
others. I would understand hesitating contacting such an old person
(possibly in a different culture), for old software.

* * *

FWIW, let me show some techincal information around GNU Pth and
cooperative thread library.

GNU Pth is too old and not maintained in upstream any more.

While it's not official GNU package, alternative cooperative thread
library, hopefully better one, nPth, is available (from GnuPG team):

https://www.gnupg.org/software/npth/index.html

It uses OS threads system (Pthreads for POSIX system, and Windows
threads for Windows), and fully compatible to OS threads system.

If needed (well, I know that need for cooperative thread library is
rare, these days), I suggest to consider use of nPth instead.

I maintain this in upstream, release 1.8 is just out this month.


For embedded (and emulation of embedded), I maintain Chopstx (for Gnuk).
It's not included (yet) in Debian package, but available at salsa.

https://salsa.debian.org/gnuk-team/chopstx/chopstx

Gnuk emulation on GNU/Linux system uses Chopstx, it's implemented with
cooperative threads by a single kernel thread, another kernel thread for
USB/IP with Pthreads.

Happy Hacking,
--