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

perl with RPM lovin' ?

[imag0]

I can see where this can go wrong...

# rpm -i myperl.rpm

warning: libsomeshit.so not installed

# rpm -i --force myperl.rpm

warning: libsomeshit.so not installed

# rpm -i --force --nodeps myperl.rpm

segfault. core dumped.

# rm -rf /

Re:perl with RPM lovin' ?

[Aliencow]

It's more like:
# rpm -Uvh myperl.rpm
warning: libsomeshit.so not installed
# rpm -Uvh myperl.rpm someshitlib.rpm
warning: libXML is missing
# rpm -Uvh myperl.rpm someshitlib.rpm libxml.rpm
warning: mozilla is missing

Then you go berserk. You mirror rpmfind, rpm -Uvh *.rpm, end up with multiple versions of crap in different places, and corrupt the UNIVERSE.

Re:perl with RPM lovin' ?

[cowbutt]

Then you go berserk. You mirror rpmfind, rpm -Uvh *.rpm, end up with multiple versions of crap in different places, and corrupt the UNIVERSE.

I know you're exaggerating for dramatic effect, but therein lies your problem. If you're installing random packages from rpmfind.net, you deserve everything you get. Either stick to packages in your distro's native format and created for the version of the distro you're running (errata, install discs, freshrpms.net in that order) or build your own, newer packages, using your distro vendors src.rpms as a template.

If you do this, I promise you'll encounter zero problems.

Too many people think that RPMs are magically some kind of universal package. They aren't and were never intended to be.

--

Re:perl with RPM lovin' ?

[cowbutt]

The irony is that shared libraries make it *very* difficult to do a real small stripped down Red Hat installation.

It didn't take me too long (and hour or so, maybe) to get a minimal server-ready RH8 installation down to 300MB. If I removed the documentation under /usr/share/doc and a few other bits, I could probably get that down to about 222MB (this figure includes Perl and a bunch of commonly-used CPAN modules, BTW, so it's actually a trade-off between "minimal" and "actually-useful" ;-)

You can find the kickstart file in this thread.

There are too many cascading dependencies. You would be better off compiling the stuff you want statically. You'd save space.

Yeah, and then when a security problem is found, you end up having to re-compile the lot. Eww.

--

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:perl with RPM lovin' ?

[evil_roy]

Now don't go countering all this FUD with facts. This is /. .Anti rpm posts are very important, it is yet another bias that helps the zealots feel better than others.

Huh?

[eln]

How hard is it to install CPAN modules in the first place? This seems like a solution without a problem to me.

Maybe if it were easier to navigate than true CPAN, but according to that page, the way to find your module is by the first letter of that module. So what happened to browsing modules by category? This thing is useless if I need a module for a specific purpose, but I don't know the name of the specific module I'll need.

So, not only are they converting Perl modules to a format they don't really need to be in, but they're making the thing harder to use than CPAN is already.

Re:Huh?

[Aliencow]

I find it practical to have everything on the system as the same type of packages. It makes it easier to manage dependencies and updates...

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.

Re:Huh?

[NightSpots]

Two things:

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.

2) Having used FreeBSD, which has perl modules in the ports/package system, I can absolutely say that it's a nice thing to have. Being able to pkg_add a perl module in half a second, no compile time, no dependency hell, it's a good thing.

Re:Huh?

[Anonymous Coward]

Well, since you are looking for a problem, this is it: We run our servers for 3 years minimum, 5 years ideally. During that time, we may or may not need to do updates (security & bugfixes driving that for the most part). During that time, the server + HW RAID + Backup could fail. During that time, we may need to clone the system. During that time we may have reason to verity the integrity of the files & the system. (You get the idea). During that time you may need to know why the heck file 'foo' is installed on the system, and how to get it to your end user systems (remember, just because it's there doesn't mean YOU put it there - many sites have multiple sysadmins).

RPMs serve as an excellent way to document what's on the system. As a benefit, you can keep them around and repeat the procedure if needed.

Imagine for a moment that you have a live production server that NEEDS to be there; you run nightly full system backups, you have mirrored hot swappable hard disks. Now, something goes wrong and you need to rebuild- terribly wrong, all 15 backup tapes were lost, and the mirrored drives are corrupt; it's 3am and you get the page to come into work. Can you put your system together again? That's but one possible scenario.

Imagine for a moment your sidekick admin, who's since quite, built the system without your knowledge. You need to do that again- what did he do? what's installed? how do you reproduce it? OH, and of course your coworker had almost next to no documentation on what specifically they did.

Having RPMS isn't about the 'ease of install' - installing the software is easy! It's about the ease of ongoing maintenance & accountability for the system. Debian packages fall into the same category.

In addition to above, a more familiar way of looking at it; look at all the crap that builds up in windows as you add/remove software. Eventually, you need to reformat, etc. Installing software on Linux is similar.

3 years down the road... did ...humm... I... arg... install... Time::HiRes?

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.

Need the reverse of this

[Julian Morrison]

I use Mandrake and it is So Bloody Annoying to be asked by RPM to install perl module RPMs that I already installed (or updated) via "perl -MCPAN -eshell".

Not that this is really this guy's problem, but if anyone from Mandrake is reading, please take note. Either there needs to be some magic added to RPM so it treats perl modules as installed RPMs - or else, the dependency checks need to be able to look for the presence of actual modules.

Having to use --nodeps is both annoying and dangerous.

It solves a problem

[cspenn]

I see a lot of posts asking "Why" since perl -MCPAN -e shell is about as straightforward as it can get.

Obviously, it was created to scratch an itch, so cut the guy some slack. If you don't like it, don't install it. For him, and maybe for others who are new to it all and are just comfortable with one tool, it solves a problem.

Chris
http://www.studentplatinum.com

Re:CPAN == RPM for Perl mods

[akedia]

There are some cases where a strictly "binary-only" system would be wanted. It is possible to build RedHat servers without GCC and stripped-down C libraries for various reasons, such as really small hard drive, or security (kinda hard for users to compile rootkits if there's no C compilier available).

CPAN builds the Perl modules in the same way you would on a source-based distro. It downloads the tarball, unzips it, does a

./configure

, checks for dependencies, then does a

make

and

make install

. RPMS don't require compiliation, and for systems lacking a C compilier, or systems with many Perl modules to install, this can be very useful. Try to imagine downloading and compiling the entire CPAN archive. It would take a week even on a fast system. Let the developers build it on something massively distributed and release an RPM that takes a few minutes to install.

BSDPAN

[Moridineas]

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

-1 Troll

[danyoung]

# rpm -i myperl.rpm warning: libsomeshit.so not installed

Uh, I'd just do:

# yum install myperl.rpm
Resolving dependencies
libsomeshit-1.0 needs be installed. OK? (y/n)?

What's the problem again?

Good idea!

[Daniel Quinlan]

A lot of people seem to be really missing the point of this idea and seem to be making what I would call the "waaah! you can't be a real perl hacker if you like this idea" response.

First, a number of Perl packages already ship in RPM format and are distributed with Red Hat and other RPM-based distributions. This will integrate much more nicely and if package names are chosen well, it will avoid conflicts between CPAN-installed packages and RPM-installed packages. I myself use Debian and always use the Debian package instead of CPAN if it's available. It's easier, it's faster, and (in the case of Debian) you get various fixes that might not have made it into the upstream.

Once you're using some packages for Perl stuff, you might as well try to get everything in the distribution package format. In addition, I think the more appropriate question is why it's taken so long for someone to think of and then implement this idea. Why on earth would you want to use more than one package management system on your box, especially when CPAN is just for Perl packages. Using CPAN when RPM packages are available might even be silly (provided the packages are well-constructed, I don't know that they will be).

Plus, the truth is, CPAN is cool and all, but it's not all that great. The usage is bizarre and if an average user isn't a Perl person, then why should they need to learn perl to install some perl-based package that depends on some CPAN modules? CPAN also is just plain inferior to RPM and .deb when it comes to installation, deinstallation, configuration mangagement, upgrades, and just about everything else.

Now, I just hope they decide to do the same for Debian packages. (Debian provides quite a few already, but more is better.)

Re:What exactly was wrong with...

[joe_fish]

From having fought to get Bugzilla installed for about 2 days, most of the time being spent using -MCPAN can say with feeling - everything.

No uninstall.

It is yet another package system to learn

I didn't work without quite a bit of hacking (but perhaps you can blame Solaris for this)

It isn't exactly a logical syntax, compare perl -MCPAN -e 'install "Foo::Bar"' with apt-get install foo-bar

And I want the dependency system to work with my systems dependency system, and not in a parallel universe.

The Java-RPM system over at JPackage.org is good and useful, I hope this will be similarly useful.

Perl programmers can (and probably will) carry on using cpan, the rest of us can have an easier life when red-carpet or apt-get just does the right thing.

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]#