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. === Al
On 9/4/07, Al Sparks data345@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.
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@gmail.com wrote:
On 9/4/07, Al Sparks data345@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@centos.org http://lists.centos.org/mailman/listinfo/centos
On 9/4/07, Gary Richardson gary.richardson@gmail.com wrote:
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.
This works too, but requires that you stay on top of security updates yourself, rather than relying on the distribution updates. If you're willing to take on the extra load, it'll work just fine.
-
Al Sparks -
Gary Richardson -
Jim Perrin