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....
Before we get there and have a fully automatic system for that - how about adding a standard POD section with instructions how to install the OS dependencies? This is something that does not require any fancy tools - it's just a custom - and once this is widespread we'll have much more data available for designing the automatic tools.
You are asking for a perl operating system.
Which is fine, and cool, but really hard. The complexity that the APT system glosses over for the end user is significant, which makes it all more amazing that called 'aptitude install foo' just works.
I don't think cpan can or even should know about operating system dependencies. How would you manage kernel dependencies for example? Surely cpan doesn't want to be in the business of installing a new kernel? How are you going to test all this stuff? The CPANTS is awesome, but their tests will have to grow exponentially if you want to test dependencies too, which is what debian does.
There is a project that builds a UNIXy OS which allows you to install multiple versions of a package without conflict; http://nixos.org/. This might be a better intermediate step.
Modern operating systems have thousands of applications, to ask cpan to manage that is just not feasible.