On Wed, Sep 28, 2011 at 7:47 AM, Jeffrey Ollie wrote:
> I totally agree, but since I can't get rid of cPanel and I don't want
> to go to the trouble of building RPMs for just one system I'm kinda
> stuck doing it the "wrong" way.
You might investigate cpan2rpm. It works smoothly for many CPAN
mo
Assuming cPanel's Perl isn't too "special" you might just grab the CentOS
SRPM, tweak the dependencies so it will install, give it a custom version
number and rebuild. You would then use Yum's version pinning module to
block any patches for that specific package to avoid future issues. I
totally
On Sep 28, 2011, at 7:47 AM, Jeffrey Ollie wrote:
> On Wed, Sep 28, 2011 at 9:33 AM, jcbollinger
> wrote:
>>
>> Doing otherwise introduces a significant risk of incompatibilities
>> arising and even your Perl modules being mangled, plus it makes
>> management more than twice as hard.
>
> I to
On Wed, Sep 28, 2011 at 9:33 AM, jcbollinger wrote:
>
> On Sep 27, 11:13 am, Aaron Grewell wrote:
>> We're not using CPAN. Modules are installed as RPMs in our environment.
>
> As it should be on an RPM-based distro.
Yes, I wish it could be so... Unfortunately the one system that I
need this f
On Sep 27, 11:13 am, Aaron Grewell wrote:
> We're not using CPAN. Modules are installed as RPMs in our environment.
As it should be on an RPM-based distro.
I strongly recommend installing software only via the system's native
package manager. If you violate that by installing Perl itself so
We are using ActiveState perl so we compile ppms from cpan modules. I
created a definition based on this page:
http://www.windley.com/archives/2008/10/using_puppet_and_cpan.shtml
It works pretty well for us. Ideally, a provider would be better than
a definition, but this works in the mean time.
