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 application. 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 > upgrade. > > > > 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 > tried > > 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 > http://lists.centos.org/mailman/listinfo/centos > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20070904/da4d6074/attachment-0004.html>