Using external installers with CPAN Clients
A lot of work is currently underway to improve CPAN. One longstanding issue is the handing of external dependencies (the "libfoo" problem.) As I understand it, although CPAN distributions may test for external dependencies, existing build tools are unable to install non-perl libraries, header files or compilers.
Resources to solve these problems are available, but in places not usually considered by CPAN toolmakers. I'm referring to native OS package repositories. While natively packaged CPAN distributions necessarily lag current CPAN offerings, they meet non-perl as well as perl dependencies, and are generally troublefree to install.
To give the example I know best, Debian's perl repository covers roughly 10% of CPAN, including much of CPAN's best. This enormous investment in labor, toolchain development and community building results in high-quality packages that even new users can install easily.
As a developer of a perl audio application available for Debian, I've encountered problems managing dependencies when administering systems that mix distro and CPAN sources, even when using local::lib.
One issue is that CPAN clients will always fulfill a distribution's dependencies from CPAN, even if native packages are available.
I'd like to suggest a small but significant step to bridge this divide between native and CPAN repositories: a native installer option for CPAN clients.
After a few false starts, here's a working demonstration: a patched version of cpanminus that supports multiple native installers.
You can invoke it like this:
cpanm --distro Debian Some::Module
causing cpanm to execute:
$distro_installer = eval {require "CPAN::NativeInstaller::Debian" }
$distro_installer then gets a chance to provide a native package for each distribution cpanm seeks to install. With this added ability, CPAN client users can install perl distributions from both native and CPAN repositories, and finesse the libfoo problem for a significant portion of CPAN.
What better way to encourage the resurgence in perl popularity than to help application developers administer their systems?
I blog about Perl.
Not such a crazy idea. Although we tend to prefer cpan as our installer, many of the sys/dev/ops people I work with really, really hate not being able to use rpms or debs, etc for everything. The more we can do to promote that type of interoperability, the better.
I agree completely. Already cpanminus lets the user specify a URL to download from, or a local file or directory. Then it installs any needed dependencies.
If we're going to offer that flexibility, it makes sense (to me at least) to let the user specify that the dependencies be provided by by InstallerX.
As developers, we used to build our own perl module debs using dh-make-perl and what not. Then setting up the repository.
But nowadays we find that maintaining our own per-project perl5/ using cpanm is so much easier (e.g. "cpanm dir from that arch's build, etc).
But yeah, choice is good.
Today I only just learned of the debian repository at http://debian.pkg.cpan.org that contains automatically generated packages of some subset of recent CPAN modules.
So for Debian users, at least, there is an option to get recent CPAN offerings without the local::lib approach.
Also of interest: cpan2pkg.