Bug#960909: pkg-perl-tools: Add Lintian check for dependency on deprecated libany-moose-perl
intrigeri at debian.org
intrigeri at debian.org
Mon May 18 07:41:35 BST 2020
Package: pkg-perl-tools
Version: 0.60
Severity: normal
Hi,
in 2012, mst documented¹ why the design of Any::Moose was problematic,
and why Moo solved the same class of problems in a better way.
In 2015, the upstream maintainers of Any::Moose² marked it as
deprecated and filed bug reports upstream against tons of reverse
dependencies. The next year, they added a runtime deprecation warning
at runtime, which made Niko notice this problem: it made autopkgtests
fail³ out-of-the-box. Then, we started tracking Any::Moose reverse
dependencies⁴ via the any-moose usertag.
I argue that the more reverse-dependencies of Any::Moose we include in
Debian,
- the less nice we are to Any::Moose upstream, who have been trying
since 5 years to discourage folks from using it;
- the less nice we are to our end-users, who can easily get stuck in
solutions that are technical dead-ends (lots of the code I've seen
use Any::Moose is effectively abandoned upstream since 2-10 years);
- the more complicated we make life for Debian-using Perl developers
who need to pick an OO toolkit and have to choose between so many
options, including current best practices, deprecated tools
(Any::Moose), and some that are essentially on life support
(Mouse ← I may come after this one later);
- the more we're increasing technical debt that we, the Debian Perl
group, will have to repay some day. I'd rather see our efforts
focused on packaging stuff that has a future.
I propose a two-fold strategy. This bug report is only about (a) but
I believe the big picture can help understand how a Lintian fits into
it:
a) Avoid things getting any worse than they currently are
To do so, decrease the risk we upload NEW packages that depend on
Any::Moose; and make it more obvious that something fishy is going
on, if a new upstream release introduces a dependency on
Any::Moose.
→ Add a Lintian check. That's what this bug report is about.
A rebuttal could be that in the current state of things, if the
maintainer does not take any action, the autopkgtests will fail,
which already provides a somewhat loud warning. However, that
warning does not provide any insight about the context, so I expect
than instead of serving educational purposes, it yields "meh, let's
just add this to use-whitelist and ignore the noise" reactions.
A Lintian check could explain things better.
b) Significantly decrease the number of Any::Moose reverse
dependencies in Debian; at this point I'm not aiming at reaching
0 reverse dependencies (yet?).
→ Each of these reverse dependencies now has a bug report in our
BTS⁴, with a proposed course of action most of the time, and
a corresponding upstream bug report. In many cases it sounds
reasonable to remove the package (low popcon, no reverse dependency
or they're themselves obsolete, abandoned upstream). In some cases
it feels it's too early (somewhat more important module, or no
upstream bug report filed until yesterday so I'd like to give
upstream some time to react.
[1] https://shadow.cat/blog/matt-s-trout/moo-versus-any-moose/
[2] https://metacpan.org/release/Any-Moose
[3] For example, #845772. I believe we added workarounds
to make all affected autopkgtests ignore this warning.
[4] https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=any-moose&user=debian-perl%40lists.debian.org
Cheers!
More information about the pkg-perl-maintainers
mailing list