Bug#747628: perl: module deprecations / removals in 5.20

[Dominic Hargreaves]

On Sat, May 10, 2014 at 04:44:14PM +0300, Niko Tyni wrote:
> Package: perl
> 
> As of 5.19.11, the following modules are becoming deprecated in 5.20:
> 
> cpan/CGI/lib/CGI.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Apache.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Carp.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Cookie.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Fast.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Pretty.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Push.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Switch.pm:use if $] >= 5.019, 'deprecate';
> cpan/CGI/lib/CGI/Util.pm:use if $] >= 5.019, 'deprecate';
> cpan/Module-Build/lib/Module/Build.pm:use if $] >= 5.019, 'deprecate';
> cpan/Module-Build/lib/inc/latest.pm:use if $] >= 5.019, 'deprecate';
> cpan/Module-Build/lib/inc/latest/private.pm:use if $] >= 5.019, 'deprecate';
> cpan/Package-Constants/lib/Package/Constants.pm:use if $] >= 5.019006, 'deprecate';
> 
> So we need to package Package-Constants separately, and start recommending
> libcgi-pm-perl, libmodule-build-perl, and libpackage-constants-perl.
> 
> Module-Build deprecation warnings are probably going to be numerous in
> build logs.
> 
> I'm not quite sure how we should treat those modules that have been
> removed between 5.18 and 5.20. In #702096 I wrote
> 
> > We probably need to package all of these separately. If jessie is going
> > to release with Perl 5.18, adding them as recommendations to the perl
> > package should be enough. If we release with something later we probably
> > need real dependencies for one release cycle.
> 
> Now that we're aiming for 5.20 in jessie, do we need to bite the bullet
> and add the hard dependencies? I sort of think recommendations might
> be enough after all.
> 
> AIUI, the concern is that without the dependencies, users upgrading from
> wheezy will have their programs silently broken by disappeared modules,
> as they are skipping those upstream releases with deprecation warnings.
> But why aren't recommendations adequate for that? Users that have
> configured apt to ignore recommendations have explicitly indicated that
> they prefer disk space savings over safety guards, IMO.
> 
> The other POV is that upstream manages module removals carefully, making
> sure that users will see the warnings, and we should be as careful not
> undermine that.
> 
> A full list of relevant removals is
> 
>  libarchive-extract-perl 
>  libb-lint-perl
>  libcpanplus-perl
>  libfile-checktree-perl
>  liblog-message-perl
>  libmodule-pluggable-perl
>  libobject-accessor-perl
>  libpod-latex-perl
>  libterm-ui-perl
>  libtext-soundex-perl
> 
> (I note that we don't have a separate package for Version::Requirements,
>  the only module that was removed in 5.18. This is as discussed in
>  http://lists.alioth.debian.org/pipermail/perl-maintainers/2013-March/003495.html
> )

Hmm, for 5.14 we ended up with Depends for the reasons you describe, but
I think your point is a fair one; Recommends is probably strong enough.
The other way of looking at it is whether there are situations in which
having them as Depends would be actively harmful. It does feel slightly
wrong that we are forcing packages of code which is being explicitly
removed from core to be installed again on all systems, so I'd be happy
to go with Recommends in the absence of specific issues which would
merit Depends.

Dominic.