The discussion of Helping Perl Packagers Package Perl glossed over a couple of points I find incredibly important. Granted, I neglected to mention BSDPAN or Gentoo's g-cpan or projects such as GoboLinux's /System/Aliens.
Yet there's more.
Working with CPAN can prove difficult in a couple of ways. The first is initial configuration:
- Do you want to install or upgrade distributions which may conflict with the system Perl 5 and any system utilities?
- Do you have permission to install into system directories?
- Which mirror repositories are best to use?
- Which utilities do you have installed that the CPAN client may want to configure or to use?
- Do you want a local installation location?
- Do you want an application-specific installation location?
That's why a smarter CPAN client configuration system is useful, and that's why an OS-specific or distribution-specific configurations would be helpful.
The other place where CPAN can be troublesome is installing distributions with non-Perl components. Consider, for example, bindings to libxml. A CPAN distribution needs to indicate somehow that it expects a specific version of a shared library called libxml.so or libxml.dylib or libxml.dll.
The CPAN client could avoid a lot of fragile, platform-specific guessing if it could ask the local packaging system for the appropriate information about that dependency. It could even invoke the local packaging system to install it.
There are dependency versioning concerns; this represents a lot of code to write and some complexity. Yet it also merges two separate systems which perform essentially the same function.
Integration with the packaging system also means that distributions which have components which require compilation can depend on packages including the header files for Perl 5 and any shared libraries, as well as a compiler and make utility and linker and....
(A lot of this problem goes away if a project such as a port of ctypes from Python to Perl 5 appears. Dependency resolution is still an issue, but the need for a compilation environment disappears in many cases.)
The CPAN infrastructure -- with local::lib configured -- has an advantage over most packaging systems I've used on free Unix-like operating systems, in that CPAN allows parallel installation of potentially conflicting libraries. This is a limitation of packaging systems.
Of course, none of this works on operating systems without packaging systems, so Windows and Mac OS X users again have trouble. At least the improved CPAN configuration (and better distributions of Perl 5) as well as a ctypes system will help them anyway.
If I could wave a magic wand, I'd love to see an easy way to package a Perl 5 application and its dependencies to create a package for a modern free Unix-like system....