How to store data for a perl module

Scott Penrose scottp at
Sun Feb 24 04:17:12 CST 2002

Hash: SHA1

On Sunday, February 24, 2002, at 09:05 , Joshua Goodall wrote:
> Sure there is, but it's not absolute: put it where the installation
> platform's *sysadmin* would expect to find it, and make it simple
> for a packager to vary it. Under a *nix, that usually means a choice
> between /var, /usr/local/lib and /etc (implying it gets changed by
> normal runtime, by installation, or by configuration, respectively).
> Some Unices vary widely; e.g. debian users might want /usr/lib,
> but under FreeBSD you'd be in /usr/local/libdata; Solaris admins
> might expect /opt.  You'll end up suggesting defaults in Makefile.PL;
> then when the module is packaged for target OS's by package
> maintainers, they can override your defaults.
> Under java, which is effectively a platform in itself, this rule
> means putting it in the jarfile and specifying that it should be
> reachable via the classloader, or a similar abstraction thereof.

This of course implies along with Jeremy's advice that I must have a 
separate set of data for each of my language installs.
Which of course means to me it is a missing feature of perl - one I will 
have to look at :-)

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 :-)

- ---
Scott Penrose
Open source and Linux Developer
scottp at
Version: GnuPG v1.0.6 (Darwin)
Comment: For info see


More information about the Melbourne-pm mailing list