How to store data for a perl module

Joshua Goodall joshua at
Sun Feb 24 08:30:12 CST 2002

On Sun, Feb 24, 2002 at 09:17:12PM +1100, Scott Penrose wrote:
> Did you get a chance to look at my other message Josh? There is a 
> difference between normal package install and cpan modules. The theory 
> behind CPAN modules is that they are platform independent. Either CPAN 
> has to understand the concept of resources, or you have to be asked 
> manually / non standard location - ala what CPAN modules do know, which 
> sort of combines CPAN and normal tar installs... Oh well the more I look 
> at this the more I realise there is no solution other than the manual 
> intevention of the installer :-)

The FreeBSD Ports/Packages people solved this by introducing
BSDPAN which forces CPAN modules to actually mesh with the
platform-specific packaging system, registering themselves and so
forth. It works by overriding various MakeMaker methods (a nice
object-pattern-based solution), and can IIRC be found in FreeBSD

CPAN is very poor as a package management solution, and this kind
of technique overcomes its limitations in ways that sysadmins
like me (with hundreds of (unfortunately not FreeBSD) boxes to
co-manage) find consistent and conducive to administrative harmony;
that is, I can then distribute a native binary package to my boxes.

Several interesting threads on the topic run from:

Incidentally - when I've needed to have configuration data shared
between Java & Perl, I've had the default file in the
.jarfile (which is usually in the classpath) but been able to
override it by prepending (prior to VM startup) the location of an
external alternative to the classpath itself; the standard classloader
will find the alternative, thus opaquing the default. Non-reusable
java classes (e.g. the execution monitor of an application server),
however, often ignore this convention and ask for full paths anyway.


More information about the Melbourne-pm mailing list