CPAN install nightmare

[Ian Cameron]

Thanks for your response, very helpful indeed.

Dave Evans said:
> > How is the location of installed modules decided?
> 
> Each installation of Perl has a whole bunch of "Config" values (which were
> chosen when perl was built), including things such as where to install
> modules, where to install `bin' or `sbin' files, etc.  For example, try typ=
> ing
> `perl -V:sitearch' to see where (IIRC) CPAN will tend to install modules.
> 
> > How does Perl know where to look for them?
> 
> Each `perl' executable has a compiled-in default search path.  Type
> `/path/to/perl -V' to see the default list.

OK, so /usr/bin/perl does its stuff under /usr/lib and /usr/local/bin/perl 
does its stuff under /usr/local/lib.  Makes sense, and nice to know for sure 
where each executable is looking.

> > Can modules installed under each setup be used together, and if so how?
> 
> Sometimes (in fact, usually).  However, it's not usually a good idea.
> You would do this by adding the extra directories to the lib search path, e=
> .g.
> using `perl -I ...' or `use lib ...'.

OK.  I can see that being a PITA whatever way you try and do it anyway, so it 
does seem like something that's best avoided.

> > The new perl is the one in /usr/local/bin, which is 5.8.8, the one in
> > /usr/bin is 5.8.5 and came via the RHEL RPM's.  I presume the 5.8.8 versi=
> on
> > was installed to satisfy a dependency when I installed one of the other
> > modules.
> 
> Sounds convincing.  Sometimes a module will decide that it requires a
> whole new version of Perl, so CPAN will "helpfully" download and install a =
> new
> Perl for you.  And no, I've never found this to be a useful behaviour. :-(

I found out which module it was, and realised that it is already available on 
the system, so hopefully it won't be necessary to update it, thus avoiding the 
perl update.

Presumably you can't disregard the new updated perl if you have to get a newer 
version to install a module though?  I'm guessing you either go without it and 
also whatever it is that requires it, or you end up having to spend quite a bit 
of time installing all the modules present in the older version for the new 
version to support previously installed applications?

> Personally what I would do now is disregard the new perl (i.e. the one under
> /usr/local), and try installing the modules you require using the packaged
> perl.   Beware: when you start CPAN (e.g. by typing 'cpan', or 'perl -MCPAN=
>  -eshell'),
> make sure you type the full path to the correct perl / cpan.
> 
> For example,
>  "/usr/bin/perl -MCPAN -eshell"
> will install things under your RPM'd perl, whereas
>  "/usr/local/bin/perl -MCPAN -eshell"
> whill install things for your new /usr/local perl; whereas the behaviour of
>  "perl -MCPAN -eshell"
> depends on which `perl` is in your $PATH first.
> 
> Did that make sense?

Yup, makes sense thanks.  I intend to rip out the perl installation under 
/usr/local, as I think it's only going to make things difficult otherwise.

OK, I've gone back through the modules install using /usr/bin/cpan each time, 
and this has helped a lot.

I also used /usr/bin/perl with a Makefile.PL as well, and this has meant that 
the package in question went into /usr/lib and not /usr/local/lib.

Looking good so far.  Thanks for clearing that up for me.

-- 
Cheers, Ian.