I think there are times when a distribution should be removed from CPAN entirely. If a distribution doesn't appear to be used, and there are other dists providing the same functionality which are being used, then I think we can consider removing it from CPAN. In this post I'll describe why it's good for CPAN if appropriate distributions are removed, how to decide what distributions should be removed, and suggest a process for distribution removal.
There are many different user groups for CPAN, but here I'm thinking about Perl programmers who don't consider themselves part of "the Perl community", who don't read perl blogs, Perl monks or hang out on IRC. They just want to get a job done, and go to CPAN thinking "I wonder if there's a module for doing X". If X is at all common, then often there will be multiple modules for it.
Sometimes there are modules / distributions for which there is no situation in which you could recommend their use, and where other distributions provide the same functionality and more. Where such distributions are probably not being used, then I think their removal should be scheduled, following the process outlined below.
But first, how might we decide what distributions are candidates for removal from CPAN?
There are lots of distributions on CPAN with version 0.01. I'm going to start looking at distributions from this group that were released more than 5 years ago and that don't have any other distributions dependent on them.
The majority of this process is actually giving notice that you plan to remove the distribution from CPAN and scheduling it far enough in the future to minimise the probability of pulling the CPAN rug from under anybody.
Pick a deletion date in the future, for example a year from now.
Release a new version of the distribution with updated documentation:
Mark it as deprecated in the one line description. For example
=head1 NAME Foo::Bar - module for doing something (DEPRECATED)
The first line of the DESCRIPTION should make it clear that you don't recommend using this module, that there are other modules you can use listed in the SEE ALSO section, and that this module will be deleted from CPAN in the future. Also link to the BackPAN directory here.
Make sure the SEE ALSO section lists all appropriate modules / distributions that could be used instead of this module.
List your BackPAN directory in the SEE ALSO section.
This way if someone has your module installed, then later decides they want to reinstall it for some reason (perhaps on a new machine), the documentation they have will tell them where they can find a copy. And you could point out that dists can be installed directly from BackPAN, for example with cpanm.
Give co-maint permission to the HANDOFF user on PAUSE. If someone else wants to take the distribution forward, making it easy for them to take it over.
If you're not familiar with the HANDOFF and ADOPTME pseudo-users on PAUSE, read my blog post about them.
If anyone else has releases of this dist on CPAN, presumably earlier than yours, then ask them to delete their releases. Otherwise when you delete yours, theirs will become the most recent release on CPAN. You should also ask them to free up their permissions for the modules in the distribution, which they can do using the PAUSE web interface. If you're the owner of the modules, then you can do it.
Wait for time to pass ... and when you reach the scheduled deletion date:
There are a number of reasons often given when arguing against deleting dists from CPAN, including:
I think this is a trade-off between (a) the chance that someone might be using it or might use it in the future, and (b) the negative impact of the distribution distracting people looking for the right module to use.
I think if there are enough alternative distributions that are being used, and the distribution meets the criteria outlined above, then CPAN is better off without it. If it turns out that the dist is being used, then you can always put it back anyway.comments powered by Disqus