Hi David,
Sorry for not replying faster.
On 2025-01-21 00:12, David Prévot wrote:
On 20/01/2025 08:25, Andrius Merkys wrote:
On 2025-01-19 12:16, David Prévot wrote:
This package hasn’t seen any upstream activity for a few years, and has
no dependencies (besides php-text-captcha, but the same can probably be
said about it) in Debian. Given how PHP has changed in the mean time, I
doubt it’s even still working. Let’s not release Trixie with a useless
and abandoned package (unless someone disagrees before the freeze), and
let’s get it removed from Debian soon too.
Seeing "Useless in Debian" bugs being filed I thought that such PHP
modules were either absorbed in PHP core, or found to be incompatible
with Debian (such as Windows or OSX-specific modules).
I mostly started with the package I maintain, trying to find out if they
were still useful: most PHP libraries have been introduced because
they’re used by another package, but is it still the case? I then
extended to packages handled by the team, and may have found a few more
on the way.
My initial goal is to ensure we don’t release Trixie with actually
useless or broken packages (I’ve stumble across bug report about
packages that are broken in Bookworm, and were still in testing), and if
possible stop trying to fix useless packages at every transition.
I understand the appeal of a cleanup. Actually broken packages are
uncontroversial to me: if they fail to build/pass tests, or are
otherwise shown to be broken, then yes, they should not stay in trixie.
But marking all packages lacking upstream activity for removal is quite
drastic to me. Apart from popcon, we have too little information on
packages being useful/useless outside Debian dependency tree. Thus we
risk upsetting the Debian user who finds their otherwise perfectly
working package no longer supplied by Debian.
Moreover, it would be nice to have some evidence for claim that this
package is not working anymore. The package builds successfully and it
worked last time I checked (although I use its reverse dependency php-
text-captcha).
For these packages, I’ve noticed the lack of upstream activity for years
(over ten years for php-text-captcha). I’m genuinely surprised they
could still be working, and given the amount of security issues
regularly fixed in PHP packages, I admit also a bit worry.
Indeed, php-text-captcha has grown layers of patches throughout these
years. Nevertheless it works, and there are no known CVEs on it. The
package is really simple, and I believe it can stay secure throughout
the years.
In some other teams I am in, lack of upstream activity does not affect
package usability. For example, libparse-yapp-perl in Perl Team, which
gets a release once 7-10 years, but very rarely gets a bug report and
has only minor patches. But then Perl is quite a stable language.
I use this package in my $DAYJOB, thus I would prefer to keep it in
Debian, unless there are strong reasons against it. I agree that there
is no upstream activity for a few years, but this is a rather simple
package and it still builds and works (with patches).
Thank you for confirming that this package is still useful, hereby
closing this report as “someone disagrees before the freeze”. I’ve
noticed in the past that people sometimes notice these kind of report
when the packages got removed from testing, and I was a bit uneasy to
start such a clean up late in the release cycle, so thanks again for
your quick reply.
Right, I agree that such cleanups should probably happen early in the
release cycle. Thanks for closing the bug.
Best,
Andrius
