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!
