Re: Any::Moose deprecation
Hi,
I kind of remember this story so googled a little bit for it and found
http://shadow.cat/blog/matt-s-trout/moo-versus-any-moose/
I do not know this might be a bit drastic.. should we try to convert modules to
use Moo instead? (and send patches upstream)
In not all cases it is trivial e.g:
https://rt.cpan.org/Public/Bug/Display.html?id=88716
in other cases it might be.
(also we could ping mst?)
Regards,
Tamas
On Thu, Nov 24, 2016 at 09:53:01PM +0100, gregor herrmann wrote:
> On Wed, 23 Nov 2016 23:18:13 +0200, Niko Tyni wrote:
>
> > libany-moose-perl_0.27-1 recently entered sid, the only upstream change being
> > add deprecation warning when this module is used
> > As a result, many (most?) of its reverse dependencies now warn on usage:
> > % perl -we 'use Path::Dispatcher'
> > Any::Moose is deprecated. Please use Moo instead at /usr/share/perl5/Path/Dispatcher.pm line 2.
>
> Thanks for bringing this up.
>
> > This change therefore triggered a dozen autopkgtest regressions [2]. More
> > may still be upcoming; I'm not sure what the re-test scheduling logic
> > on ci.debian.net currently is. Also, our autopkgtest coverage is "only"
> > at 81%, so there may be affected packages that aren't caught by these
> > checks. (It looks like libpath-dispatcher-perl is one of these.)
>
> % reverse-depends libany-moose-perl
> Reverse-Depends
> ===============
> * alice
> * libanyevent-gearman-perl
> * libapp-perlrdf-command-query-perl
> * libbot-training-perl
> * libconfig-jfdi-perl
> * libdata-amf-perl
> * libmethod-signatures-perl
> * libmousex-types-perl
> * libnet-google-code-perl
> * libnet-jifty-perl
> * libnet-trac-perl
> * libpath-dispatcher-declarative-perl
> * libpath-dispatcher-perl
> * libprophet-perl
> * librdf-crypt-perl
> * librdf-helper-properties-perl
> * libterm-editoredit-perl
> * libtest-cukes-perl
> * libtext-clip-perl
> * libwebservice-solr-perl
> * libwww-nicovideo-download-perl
> * openpgp-applet
>
> > I'm wondering what (if anything) we should do about this, mainly for
> > stretch at this point in the release cycle. Do we want to release with
> > these packages issuing warnings on usage, or should we look at either
> > fixing/squelching the warnings somehow or even removing the packages
> > from Debian?
>
> Leaving the warnings looks a bit unattractive; removing the rdeps is
> a bit drastic, OTOH this might be a good trigger to clean up a bit.
> But this needs work, and my hunch is that we won't get rid of all of
> them for one reason or another.
>
> Just commenting out the deprecation warning in Any::Moose would be
> easy, although it feels a bit cheap. But maybe there's an argument to
> be made for it as the target audience for the warning is not the
> average user of some automatically installed Debian package but the
> authors of the rdeps?
>
> Not sure what's best ...
>
>
> Cheers,
> gregor
>
> --
> .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
> : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
> `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
> `- NP: Leonard Cohen: If I Didn't Have Your Love
--
CSILLAG Tamas (cstamas) - http://cstamas.hu/
"Real programmers can write assembly code in any language."
-- Larry Wall
Reply to: