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 nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
