Not packaging CPAN is a mistake. It is the normal way of distributing program dependencies, even for programs that are not distributed via CPAN themselves.
Every program written in Perl that you would want to install manually comes with install instructions that includes using CPAN to get the required libraries installed. That's the culture and it has served well for the past fifteen years or so. The alternative would be to include all dependencies in all programs, which would be worse.
A system without CPAN would leave many beginning system administrators very confused on how to proceed and give Perl programs an unfounded reputation of being hard to install. There should at least be a stub installed that brings in the real stuff when called for or at least explains the situation.
Posted Aug 27, 2009 8:21 UTC (Thu) by Cato (subscriber, #7643)
[Link]
The best option would be to package CPAN and also include a default configuration for it that avoids it trampling on distro managed directories, e.g. use /usr/local/CPAN for all CPAN-installed (or upgraded) packages, and a suitable Perl library path so that everything uses this tree first. Then the Perl user can use CPAN and know that anything installed by CPAN takes priority over the version in the distro, while still being able to upgrade the distro's Perl-based packages.
What would be even nicer is a simple tool that, given a CPAN package name, first tries the distro's packaged versions of CPAN packages, and only if they don't exist tries CPAN directly.
CPAN is required for all third party software
Posted Aug 28, 2009 15:41 UTC (Fri) by epa (subscriber, #39769)
[Link]
...better still, first tries the distro's own repository, then attempts to
get the package from CPAN and build a package of it using a tool like
cpanflute2, cpan2rpm, makerpm.pl, etc etc.