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)
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
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.
perl -MCPAN -e 'install SomePerlModule'?
It would get compiled for your system, warning you and/or downloading all the required dependencies.
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.
Except this thing requires a network connection too! And CPAN, IIRC, is a standard part of Perl, so if you don't have CPAN, then you don't have Perl, and thus have no use for CPAN.
In the FAQ, it states that the reasons for doing this are 1.) cool points and 2.) to hawk his book (okay he doesn't say that in as many words). Plus, it's written as a shell script, because shell scripts are portable. There is no explanation given as to why he couldn't have written it in Perl, since any system that would have any use for it at all would have Perl installed.
So, basically, he's taking the awesome resource that is CPAN, making it less useful, less portable (RedHat only), more obtuse, and more prone to error (only "around 90%" of the modules work right). Yah, this seems like a really great idea to me.
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
Subscribe for free to my show!
CPAN builds the Perl modules in the same way you would on a source-based distro. It downloads the tarball, unzips it, does a , checks for dependencies, then does a and . 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.
Already like this on FreeBSD systems. Called BSDPAN. Perl can be installed through the ports tree, and upgraded as easily.
CPAN Shell makes installation easy, yes. Now show us what the command for uninstallation is.
Also, it would be helpful if the CPAN Shell command you'll show us could warn of lingering dependencies (where package A strictly depends on B and if you uninstall B you'll be warned that if you proceed package A will not work anymore).
Digital Citizen
Uh, I'd just do:
What's the problem again?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).
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.)
/usr/bin/g-cpan.pl Module::Name
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.