Slashdot Mirror
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."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
Already like this on FreeBSD systems. Called BSDPAN. Perl can be installed through the ports tree, and upgraded as easily.
And its great! The best part is that .debs can specify dependencies on perl modules, which can then be met via apt. This has the added benefit of keeping all files under the control of the package manager... instead of floating around in limbo.
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.
Only 120 characters... who can summarize their entire world understanding in 120 characters?!
Yes, it is. Check out cpan2rpm.
The best of both worlds - modules built locally, with rpm ease of installation and de-installation.
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
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).
In 5.1-RELEASE at least, the CPAN module is integrated with the FreeBSD package system so that when you install a module via -MCPAN, it also registers in the package database. There are quite a few modules in the ports tree, but it seems easier simply to get the most up-to-date modules off of CPAN and then use pkg_* to deal with uninstalling modules and whatnot. Generating nightly RPMs of the entire CPAN tree seems like a fair amount of overhead. Are there enough uses for this to warrant it?
> 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.
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:
0 3t eTime-Format-Builder-0.758 601-0.03D ateTime-Locale-0.035 -ExtUtils-ParseXS-2.025 -IO-stringy-2.108r -Compare-0.01c apes-1.03s ter-0.09
p5-Test-Simple-0.47_1- Tabs+Wrap-2001.09290 .35
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")
Debian has (for quite a number of years, anyway) had the ability to generate a debian package from CPAN souces with a very very very minimal effort.
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
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?
/usr/bin/g-cpan.pl Module::Name
CPANPLUS, which is scheduled to replace CPAN.pm in the 5.10 core, has uninstall functionality.
/root/.cpanplus/mailrc.2.04.stored /root/.cpanplus/dslip.2.04.stored /root/.cpanplus/packages.2.04.stored /usr/local/lib/perl5/site_perl/5.8.0/File/ReadBack wards.pm /usr/local/man/man3/File::ReadBackwards.3 /usr/local/lib/perl5/site_perl/5.8.0/i686-linux/au to/File/ReadBackwards/.packlist
[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]#
--- Fox
g-cpan.pl is part of portage.. on every gentoo system. It dynamically generates ebuild scripts, downloads the source, builds the package in sandbox, merges them, putting entries in the world file, etc.
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.
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.
-
When a binary module fails to compile, you have no idea what to do. You're SOL unless you feel like debugging perl's C code; which I don't, because the reason I'm installing bugzilla is because I have my own bugs to deal with.
- When a module fails its tests, you have no idea what to do. Similarly SOL.
Lesson learned: never install a binary Perl package with CPAN. Go get the RPM for your distro, and hope it hasn't been EOL'd yet (trying to find RedHat 7.2 RPMs is a treat).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?
I can explanate how to administrate your network. You must configurate and segmentate it, so it can computate.
If its only advantage were installing all dependencies for you, it
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.)
Cut that out, or I will ship you to Norilsk in a box.