Red Hat, RPMs and Perl
scottp at dd.com.au
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
> 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
> 7.3 distribution (eg. CPAN) via RPM.
> With Debian, almost any Perl module I wanted was available as a .deb
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
> then went I downloaded something from CPAN and did 'perl
> 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
> What I want is to be able to easily install/manage/upgrade/remove Perl
> (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
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
Makefile.pl; 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 Makefile.pl; 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
> c) Do you roll your own RPM for each module? (If you do, I salute you!
> 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 Cross <gcross at alphalink.com.au>
> To unsubscribe send 'unsubscribe programmers-sig' to
> majordomo at luv.asn.au
Anthropomorphic Personification Expert
scott at cpan.org
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