Bug#580034: perl: module deprecations in 5.12.0

[Niko Tyni]

On Tue, May 04, 2010 at 01:59:55PM +0100, Dominic Hargreaves wrote:
> On Mon, May 03, 2010 at 10:57:23PM +0300, Niko Tyni wrote:
> > On Mon, May 03, 2010 at 11:52:21AM +0100, Dominic Hargreaves wrote:

> > > We should also try and file bugs against packages using these modules,
> > > if we can, once the separate packages are available.

> > so this doesn't look like a huge issue.
> 
> Indeed. Instinct tells me we shouldn't bother packaging Shell or
> Pod::Plainer, and possibly not Switch either (a quick inspection reveals
> that it's only used by a test suite which will skip the test if it's
> not loadable).

I'm a bit undecided on this.

One piece of useful input to this would be a more extensive search for any
uses of the three other modules. The build logs I grepped only include
lib*-perl modules, any other XS modules (distinguished by the perlapi-*
dependency) and all libperl5.10 reverse dependencies.

There are probably plenty of Perl applications and the like in the
archive that haven't been checked yet. I wonder if there is still a
developer accessible "lintian lab" of unpacked source packages somewhere?

Another thing: I've just tried to install all the three with /usr/bin/cpan
and /usr/bin/cpanp, and Switch and Pod::Plainer worked fine and installed
to /usr/local as they should.

However, there's a problem with Shell because it is at 0.72_01 in the
core, which is considered a development version on CPAN.  Getting either
of the programs to reinstall 0.72_01 is not easy, and forcing a downgrade
to 0.72 doesn't seem like a good idea (although the diff is pretty small
there seems to be one new feature in 0.72_01.)

This may be a good enough reason to package libshell-perl unless/until
things get sorted out on the CPAN side.

As for the rest, packaging them for the lifetime of a single release
would avoid breakage for those users who have legacy Perl scripts and
who don't see the deprecation warnings for one reason or another.

The recommendations would pull the separate packages onto the systems
automatically, and removing them from the Debian archive later wouldn't
remove them from their systems.

Having said all this, I certainly agree that packaging obsolete modules
that aren't even used anywhere feels wrong.
-- 
Niko Tyni   ntyni at debian.org