Red Hat, RPMs and Perl

Scott Penrose scottp at
Tue Aug 20 18:27:50 CDT 2002

On Tuesday, August 20, 2002, at 09:54 , Graeme Cross wrote:

> As some of you know, I have just installed a Red Hat system at home and 
> am
> slowly reacquainting myself with Red Hat.

I thought you had moved to FreeBSD ?

> I am a bit stumped on managing Perl modules that don't come with the 
> standard
> 7.3 distribution (eg. CPAN) via RPM.
> With Debian, almost any Perl module I wanted was available as a .deb 
> package.

One problem we have faced at myinternet is that you can't use two 
package management systems.
On my laptop and on my workstation (both debian) I am happy to mix 
installation from packages and via CPAN, but sometimes it means manually 
finding stuff and removing it. eg: if you install a newer version of a 
module, the pm you run may look in the wrong location for the xs file. 
But that is fine, I find that it does not take much management

However on our deployed servers we made the decision to never use CPAN. 
What we do instead is make our own .deb of the CPAN module. But it is 
easy for debian, you just use dh-make-perl and it does it all for you :-)

> With FreeBSD, many modules were available from the ports system. If it 
> wasn't,
> then went I downloaded something from CPAN and did 'perl 
> Makefile.PL;make
> install', it would register as a port.
> Both systems work nicely: you can easily install Perl modules, upgrade,
> remove, know what you've installed, etc.

What is the difference ?

> I am damned if I can figure out how to do something similar with Red 
> Hat.
> What I want is to be able to easily install/manage/upgrade/remove Perl 
> modules
> (eg. from CPAN) using RPM.

 From CPAN using RPM... Does any system have that?
You could do it in Debian by always building a .deb with  dh-make-perl, 
but I would personally find that too slow as you would have to build 
every one of the dependencies.

The biggest problem is the way people bundle.

Debian has a nice naming convention. If I build my Device::ParallelPort 
then it would be libdevice-parallelport-perl
So you can easily determine if things are available.

It has always been a dream of mine to make it that the packages fit that 
way. Then we could have CPAN style module that, on doing a dependency 
check does a install from the package name if it already exists. Plus it 
could even create dummy packages, or the real packages and install them.

Of course this could mean that we could have a fully automated system of 
building ALL CPAN modules as debian packages fully almost fully 
automatically (couple of things are done manually which we could insert 
expect scripts for) and even automatically insert all the dependencies.

EXCEPT, that lots of the perl modules (both in base Perl, Debian, RedHat 
and FreeBSD) are personal preference combinations. Thus we have no way 
of knowing automatically what is in those packages.

> I was hoping that 'perl Makefile.PL; make install' would hook into RPM 
> as it
> does with FreeBSD. It doesn't seem to.

Can you explain how it work in FreeBSD. ie: What does it actually hook 
into ?
Can someone explain how it keeps track of files installed and names and 
versions and dependencies ? And how does it hook into the above (perl; make install) when they are standard perl modules.

> So: Red Hat users -- given the small number of Perl modules that come 
> with Red
> Hat, how do you manage Perl modules from other sources (eg CPAN).

BTW. Doing a "perl; make install" is not as sensible as 
using CPAN. If you use CPAN you at least pick up all the dependencies 
and keep track of what is installed.

> a) Do you just do a 'make install' and bypass RPM?
> b) Is there a net repository of Perl module RPM packages that I've 
> missed?
> c) Do you roll your own RPM for each module? (If you do, I salute you! 
> It
> seems a lot of effort).

CPAN is fairly well structured and predictable. I am still at a loss at 
wondering why there isn't a repository of built CPAN packages for all of 
RedHat, FreeBSD and Debian, we are so close to making this possible. You 
know when you think something is logical it must already exist - well it 
must already exist :-)


> Thanks in advance,
> Graeme
> --
> Graeme Cross <gcross at>
> -
> To unsubscribe send 'unsubscribe programmers-sig' to 
> majordomo at
Scott Penrose
Anthropomorphic Personification Expert
scott at

Dismaimer: While every attempt has been made to make sure that this 
email only contains zeros and ones, there has been no effort made to 
guarantee the quantity or the order.

More information about the Melbourne-pm mailing list