Re: CPAN Question

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



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@xxxxxxxxx> wrote:
On 9/4/07, Al Sparks <data345@xxxxxxxxx> 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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux