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

Re: Question about perl organisation on disk and CPAN



On 03/04/2008, Kelly Clowers <kelly.clowers@gmail.com> wrote:
> On 4/3/08, Lesley Binks <lesley.binks@googlemail.com> wrote:
>  > Hi
>  >
>  >  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?
>
>
> I think you might run into some issues if you install perl 5.10, but I am
>  not a perl expert.
>
>  As far as installing stuff from cpan, I suggest you check out a program
>  called dh-make-perl. It wraps cpan to create a .deb of the module, so
>  you can use the package manager to manage your cpan modules. It is
>  clearly easy to use, since I got it to work without much trouble and I
>  know almost nothing about perl or cpan.
>
>
Thanks for the heads up on that option Kelly.

I have been playing around with cpan from the command line.  Useful
commands are r and upgrade or upgrade <modulename>.  r gives a list of
modules installed against the latest versions on CPAN.  upgrade will
try and upgrade all of them and upgrade <modulename> simply attempts
to upgrade the specified module.

However not all will upgrade and they are still on the shelf waiting
for me to try a fix.  One module is perl 5.10 and so CPAN or the
module writer doesn't appear to be graceful around the perl version
problem.  Others have compilation problems which need exploring

cpan is highly interactive.  Haven't tried the perl -MCPAN approach
yet. Probably useful for automated tasks

On 03/04/2008, Glenn Becker <burningc@sdf.lonestar.org> wrote:
>
>  Hi Lesley,
>
>
<snip because it's included above>
>
>  I'm glad you posted this question, since I have wondered some of the same
> things. I have a multi-OS system and have typically done my Perl-ing on my
> Slackware install, and use CPAN all the time there.
I would hope that it might be possible to run say 5.8.6 and 5.8.8 if
not 5.8.8 and 5.10.

>
>  I have run into conflicts a couple of times on Debian because I have either
> installed modules via CPAN that were in the repository or were
>  otherwise mixed up in a dependency somehow. So it is an area to be
> aware/careful in.
>
I'm not sure how up to date Slackware is on it's perl install or how
it manages perl module updates outside of cpan but I think say
libcgi-perl package provides a CGI.pm a few steps behind the version
on CPAN. If you are getting 5.8.8 stuff on both the Slackware and the
Debian box but retrieving them in different ways from differemt
sources then it is highly likely that the slackware and Debian
repositories may not contain the same version - which may or may not
be a problem.  I suspect the only route there is to use a non-distro
specific method of updating on both e.g. use cpan on both
environments.

I understand the object model has been rewriiten in 5.10 so there will
probably be different sorts of problems mixing the two perl versions
or more precisely mixing modules from the two versions because perl
5.10 will handle its oo one way and 5.8.8 another.  Not sure exactly
what those changes are or how they were implemented nor what else has
changed but am sure the info is out there on all that.

>  This document may help:
>
> http://www.debian.org/doc/packaging-manuals/perl-policy/index.html
>
>  There is also apparently a Debian CPAN of sorts:
>
>  http://debian.pkgs.cpan.org/
>
>  I found both of these via
>
>  http://www.debian-administration.org
>
>  which has proved to be a helpful site.
>
I'd forgotten about debian-adminsitration which is very useful.
and thanks for the perl-policy info ... defintely worth a read as is
the cpan package.  Half the problem is finding the documentation.

Regards

L.


Reply to: