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.

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.

-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?

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