CPAN package provider?

[Jeffrey Ollie]

Google searches don't turn up anything very promising in terms of a
Puppet CPAN package provider. What are people using to manage Perl
modules installed through CPAN?

--
Jeff Ollie

[Aaron Grewell]

We're not using CPAN.  Modules are installed as RPMs in our environment.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[John Lyman]

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.

[qutic development]

You can use a define:

define perl::installCPAN () {
exec { "cpan_install_$name":
command => "/usr/bin/cpan -i \"$name\"",
timeout => 600,
unless => "perl -e \"use $name\"",
require => Package['perl'],

[jcbollinger]

On Sep 27, 11:13 am, Aaron Grewell <aaron.grew...@gmail.com> 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 some
other way (e.g. manually), then anything goes for that Perl
installation (or Ruby, Python, ...), but if you are using the system's
Perl then you should use the system's Perl packages. If you need Perl
modules not available pre-packaged then package them yourself; it's
not that hard, especially if they are already available from CPAN.

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.


John

[Jeffrey Ollie]

On Wed, Sep 28, 2011 at 9:33 AM, jcbollinger <John.Bo...@stjude.org> wrote:
>
> On Sep 27, 11:13 am, Aaron Grewell <aaron.grew...@gmail.com> 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 for is running cPanel on a CentOS 5 system. cPanel installs
its own custom Perl (as well as many other packages, including Ruby so
I have to install Puppet and Facter via GEM rather than RPMs). I'm
trying to get munin installed on this system so that I can monitor the
system. Since cPanel installed a custom Perl the CentOS Perl module
RPMs won't install.

> I strongly recommend installing software only via the system's native
> package manager.  If you violate that by installing Perl itself some
> other way (e.g. manually), then anything goes for that Perl
> installation (or Ruby, Python, ...), but if you are using the system's
> Perl then you should use the system's Perl packages.  If you need Perl
> modules not available pre-packaged then package them yourself; it's
> not that hard, especially if they are already available from CPAN.
>
> 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 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.

--
Jeff Ollie

[Craig White]

----
high quality rationalization for such a low bar effort.

quite simple to build rpm's from cpan modules - there's consistent methodologies for doing just that.

Craig

[Aaron Grewell]

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 understand the "just make it work" idea, but if you do that this system will always be broken.  Eventually I find the broken ones come back and bite me...

[Brian Shore]

On Wed, Sep 28, 2011 at 7:47 AM, Jeffrey Ollie <je...@ocjtech.us> 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
modules. I've only seen it fail for modules that didn't specify an
author (it tries to extract that for inclusion in rpm metadata).

--
Brian Shore
Network Redux
http://networkredux.com | @devopsec