Perl Modules as RPM Packages 207
libertynews writes "KPLUG President Kevin Pedigo has just announced his latest project -- RPMPAN, an archive of CPAN Perl modules in RPM format, generated nightly."
Kleeneness is next to Godelness.
BSDPAN (Score:5, Informative)
Already Done in Debian (Score:2, Informative)
Of course, some of the more obscure modules never get packaged... so if this RPM database proves succesful, perhaps Debian could look into automating the package of all the smaller, less used modules.
Re:Huh? (Score:5, Informative)
Yes, it is. Check out cpan2rpm [cpan.org].
The best of both worlds - modules built locally, with rpm ease of installation and de-installation.
Even better in Debian (Score:3, Informative)
Mmmmmm, Debian
Don't want to (Score:4, Informative)
- 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).
Perl Modules on FreeBSD (Score:2, Informative)
Re:Huh? (Score:4, Informative)
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' ? (Score:4, Informative)
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.
p5-Compress-Zlib-1.22
p5-DateTime-0.16
p5-Da
p5-DateTime-Format-ISO
p5-DateTime-Format-Strptime-1.0302
p5-
p5-DateTime-TimeZone-0.25
p
p5-File-Find-Rule-0.11
p
p5-Module-Build-0.19
p5-Numbe
p5-Params-Validate-0.64
p5-Pod-Es
p5-Pod-Simple-0.96
p5-Test-Builder-Te
p5-Test-Harness-2.28
p5-Test-Pod-0.95
p5-Text-Glob-0.05
p5-Text
p5-Time-Local-1.07
p5-YAML-
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")
How to do this in Debian! (Score:3, Informative)
Here's how to do it in three easy steps:
Step 1: Go to CPAN and figure out what you want.
Step 2: dh-make-perl --cpan --build --install
Step 3: There is no step three!
~GoRK
Just tried this today. My results. (Score:3, Informative)
Apparantly there is a major disconnect between package dependencies and what is actually installed on a box.
I wanted to add RPC::XML to my Mandrake box, so I tried installing the rpm version. It complained about a list of about 20 failed dependencies, missing packages.
So I grabbed the tar from CPAN and did the good old make install and it mentioned that only the XML-Parser was missing.
So... would the rpm have worked if I told it to ignore dependencies, since those perl lib's were already on the box?
Re:obligatory gentoo zealotry (Score:3, Informative)
Re:Uninstall? (Score:5, Informative)
[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
Retrieving
Retrieving
Uninstalling: File::ReadBackwards
unlinking
unlinking
unlinking
Uninstalled File::ReadBackwards successfully
All modules uninstalled successfully
CPAN Terminal>
Exiting CPANPLUS shell
[root@ocicat root]#
Re:obligatory gentoo zealotry (Score:2, Informative)
It does not do updates - it doesn't 'sync' with anything. It's a mechanism to merge (and unmerge) anything that's available on CPAN.
Overall it's pretty sweet.. and needs exposure.
Re:CPAN == RPM for Perl mods (Score:4, Informative)
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.
Re:What exactly was wrong with... (Score:3, Informative)
To its credit, CPAN worked for the perl-only modules, except it wants to download the 300K index file each time you start it. Hello!? Wouldn't once per day be enough?! And WTF is with using lynx to download stuff? What is wrong with wget?
Re:perl with RPM lovin' ? (Score:2, Informative)
wouldn't be any better than urpmi or apt. CPAN is better, more
advanced than that, able to configure things in ways that rpm can't.
It's more closely comparable to portage, if anything, except that
CPAN has the additional advantage of a very large and robust mirror
system to draw from, and, obviously, that CPAN only has Perl stuff,
so you have to already have any _other_ dependencies. (For example,
CPAN can update your Perl GTK+ bindings for you, but it can't update
GTK+ itself; it can update the DBD::mysql interface, but it can't
install or update MySQL itself. This is actually a pretty major
limitation, and the best reason I can think of to use any other
package management system.)