Perl Modules as RPM Packages

libertynews writes "KPLUG President Kevin Pedigo has just announced his latest project -- RPMPAN, an archive of CPAN Perl modules in RPM format, generated nightly."

Comments

BSDPAN

[Moridineas]

Already like this on FreeBSD systems. Called BSDPAN. Perl can be installed through the ports tree, and upgraded as easily.

Re:Huh?

[jsprat]

it *is* nice to have this sort of stuff managed by your package manager.

Yes, it is. Check out cpan2rpm.

The best of both worlds - modules built locally, with rpm ease of installation and de-installation.

Even better in Debian

[addikt10]

Using dh-make-perl, you can automatically grab the latest source for any module on CPAN that isn't already included in the Debian distribution, and make a deb package for it, trivially managing future updates and installation.

Mmmmmm, Debian

Don't want to

[Julian Morrison]

I like the CPAN shell interface.

- it lets me search, and read the module descriptions (assuming the lazy sod module creator has written one).

- it lets me check what's out-of-date with a single command ("r"). It automatically keeps in sync with CPAN's module repository. It even updates itself live (install Bundle::CPAN; reload cpan).

- it doesn't merely install binaries, it runs the compile (so the result is guaranteed to work with my libs, or at least complain sensibly) and often asks for config options.

- it already does all the dependency stuff that RPM could do, and it does it cleaner and better and in pure perl. It detects actual dependencies rather than merely advertised ones. It can fetch the required modules and install them, without needing to ask.

- it does all this from a friendly unified command line app that I can run remotely over SSH on a co-lo server.

- it's in every install of perl (well, Perl-for-Windows is a special case, but that's nothing new).

Re:Huh?

[Bluetrust25]

> 1) CPAN isn't flawless: yesterday, I tried using it to install File::Temp and it tried upgrading perl from 5.6 to 5.8. That simply isn't the correct thing to do, under any circumstance.

I've found through experience with just this very thing that the first command run through CPAN should be:

perl -MCPAN -e shell
install Bundle::CPAN

Upgrading to the newest version is necessary to get it to leave perl the hell alone.

So once you get past that hurdle, I find the worst part about CPAN is that some packages which everyone uses like mod_perl, DBI, and DBD::mysql fail to install unless Apache was compiled the correct way and currently running, or MYSQL is running and allows some bullshit nameless user to access all databases (!)

In RedHat Linux 7.x (maybe 8.x and later too), the mod_perl RPM is installed by default, but Apache isn't compiled correct to play nicely with it. So if you want to actually use mod_perl's features (i.e. install Bundle::apache in CPAN) then you have to uninstall apache and compile it by hand.

Frustrat-o-rama.

But in general, CPAN rocks. If it wasn't for CPAN then perl wouldn't be as popular as it is today. Why, just earlier this evening I was thinking that I'd love for users of a web app I'm working on to be able to import data from Excel files rather than just comma-delimited, I did a quick search at search.cpan.org and WHAM, one 'install Spreadsheet::ParseExcel::Simple' later and now users can upload Excel files. I can't think of any other language that makes it this easy to find and reuse libraries.

CPAN makes me look like I'm really good at what I do.

Re:perl with RPM lovin' ?

[Anonymous Coward]

Oh yeah, like any other package system is different. You want to experience the same fun on FreeBSD? Try the following which I did last week:

portinstall -v p5-DateTime-Format-ISO8601

Pretty innocent right? I mean what the fuck is involved in parsing dates? The library *I* wrote to parse an ISO8601 subset was about two pages long. You know, dates/times like '2003-05-24' '05-25' 'T12:23:45Z' etc.

Well, after a "little while" here's what it pulled in:

p5-Archive-Tar-1.03
p5-Attribute-Handlers-0.78
p5-Class-Factory-Util-1.4
p5-Class-Singleton-1.0 3
p5-Compress-Zlib-1.22
p5-DateTime-0.16
p5-Dat eTime-Format-Builder-0.75
p5-DateTime-Format-ISO8 601-0.03
p5-DateTime-Format-Strptime-1.0302
p5-D ateTime-Locale-0.03
p5-DateTime-TimeZone-0.25
p5 -ExtUtils-ParseXS-2.02
p5-File-Find-Rule-0.11
p5 -IO-stringy-2.108
p5-Module-Build-0.19
p5-Number -Compare-0.01
p5-Params-Validate-0.64
p5-Pod-Esc apes-1.03
p5-Pod-Simple-0.96
p5-Test-Builder-Tes ter-0.09
p5-Test-Harness-2.28
p5-Test-Pod-0.95
p5-Test-Simple-0.47_1
p5-Text-Glob-0.05
p5-Text- Tabs+Wrap-2001.0929
p5-Time-Local-1.07
p5-YAML-0 .35

Can't wait to install some of these Perl RPMs on my Red Hat box........ (in this sentence, "can't wait" means "I'm not going to fucking touch this crap")

Re:obligatory gentoo zealotry

[lanalyst]

/usr/bin/g-cpan.pl Module::Name

Re:Uninstall?

[PghFox]

CPANPLUS, which is scheduled to replace CPAN.pm in the 5.10 core, has uninstall functionality.

[root@ocicat root]# perl -MCPANPLUS -e shell
CPANPLUS::Shell::Default -- CPAN exploration and modules installation (v0.03)
*** Please report bugs to <cpanplusbugs@lists.sourceforge.net>.
*** Using CPANPLUS::Backend v0.042. ReadLine support enabled.

CPAN Terminal> u File::ReadBackwards
Checking if source files are up to date
Retrieving /root/.cpanplus/mailrc.2.04.stored
Retrieving /root/.cpanplus/dslip.2.04.stored
Retrieving /root/.cpanplus/packages.2.04.stored
Uninstalling: File::ReadBackwards
unlinking /usr/local/lib/perl5/site_perl/5.8.0/File/ReadBack wards.pm
unlinking /usr/local/man/man3/File::ReadBackwards.3
unlinking /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/au to/File/ReadBackwards/.packlist
Uninstalled File::ReadBackwards successfully
All modules uninstalled successfully
CPAN Terminal>
Exiting CPANPLUS shell
[root@ocicat root]#

Re:CPAN == RPM for Perl mods

[juhaz]

Because perl modules aren't (or shouldn't be) any different from other software and should be handled by same system that handles all the other software?

Why should we have different database for perl modules than rest of the system? While we're it for perl, why not make one for c, another for c++, yet one for java, then there should be one for python, etc etc. That'd be a frickin' nightmare and best of all those wouldn't have any knowledge of each other, so if my C program depends on perl modules it wouldn't have any way of knowing if it's installed or not because it uses different package manager.

Thanks but no thanks. I want one thing to keep track of ALL software, no matter what language it's written in.