[CentOS] CPAN Question
gary.richardson at gmail.com
Wed Sep 5 03:54:43 UTC 2007
The alternative that I prefer is to install a custom perl for your
application in another location (like /opt/bin). This keeps it separate from
your system perl, so your os patches work fine and patching won't break your
On 9/4/07, Jim Perrin <jperrin at gmail.com> wrote:
> On 9/4/07, Al Sparks <data345 at yahoo.com> wrote:
> > Maybe a little off-topic. But using cpan, I tried to install
> IO::Compress::Base 2.006.
> > I already had 2.005 installed. For the life of me, I couldn't get it to
> > It finally occurred to me to download the ".tgz" file, and install it
> that way.
> > That worked.
> > But does anyone have any hints on how to force cpan to upgrade? I even
> > the "upgrade" command, and that didn't work.
> You're going to make me drag out my soap box, broken record, and dead
> horse aren't you....
> CPAN is bad on systems with package management like centos. The reason
> is because cpan doesn't inform the package management utility that
> it's installed anything. CPAN can also upgrade chunks of code which
> are provided by the perl rpm shipped by centos.
> This may not seem like a big deal until you attempt to install a
> package which requires a perl module you installed via cpan and yum or
> rpm tells you that it's not installed. Your options here are to force
> the installation, or install a copy via yum/rpm. This will result in
> either a code conflict, or multiple copies of something on your
> system. Either way things can slowly snowball and go wrong.
> The best method for installing perl modules is via package management.
> 3rd party repositories like RPMForge have dozens of perl modules which
> plug right into the centos perl packages and work like a champ. If all
> else fails and you can't find the particular perl module you need via
> one of these repositories, you should use cpan2rpm, or another
> packaging utility to create an rpm suitable for your system.
> Using package management features like this gives you reliability (you
> can install the package on multiple machines instead of hoping it
> builds identically on each one), and a 'paper trail' to follow for
> what's on your system (you can query rpm to see where a file is or
> what package owns it instead of guessing) and best of all, you can
> easily remove something without resorting to 'find /somepath -name
> something | xargs rm' or some other hack.
> Let your package manager do the heavy lifting.
> During times of universal deceit, telling the truth becomes a
> revolutionary act.
> George Orwell
> CentOS mailing list
> CentOS at centos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the CentOS