[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Question about perl organisation on disk and CPAN


I'm using Perl 5.8.8 on etch and I have a couple of questions about Perl.

My @INC is
@INC is /etc/perl /usr/local/lib/perl/5.8.8
/usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl
and, as far as I understand it this describes where perl searches for modules.

The major difference between Debian etch and other distros I have
worked on is the existence of /etc/perl which contains subdirectories
of CPAN and NET on my install.

Almost all other distros share the /usr/share and /usr/lib hierarchies
and I would like to know why the two hiearchies exist and how it is
decided which hiearchy a module will be installed.
Basically what characteristics does a module have which means it
belongs in /usr/share or /usr/lib?

I think I understand the /usr/local hierarchy as a place to put
anything that occurs locally - any locally written modules and I use
site_perl for web related modules - mod_perl for example.

I can see the latest release of perl is 5.10  so presumably one could
have perl/5.10.0 as well as perl/5.8.8 on one installation but there
might be some modules that are generic across all perl 5.x releases.

The last question relates to installing modules.  Debian provides the
apt-get mechanism, and the cpan mechanism can also be used in two ways
'perl -MCPAN ..' or just using cpan on the command line.

I assume I get the modules that have been released with etch and which
might be a few versions behind the latest for any given module when
using the apt-get option e.g. 'apt-get libcgi-perl'.

If I use CPAN what is the best method to use? Should I use the cpan
command or should I use the perl -MCPAN method?  And how much of a
problem is not having perl 5.10 installed going to be if I choose to
get the latest modules from CPAN?    Is it possible to install 5.10 on
etch or are there dependencies that might have wider effects than
simply updating perl e.g. altering the libraries that gcc relies on?



Reply to: