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.
Why exactly do they need to do this every night??
Surely it would be infinetly simpler to just rsync against the server with the CPAN modules and then only rebuild RPMS for new/modified modules.
You could even use perl to do this...
37 - what does it stand for really...
perl -MCPAN -e 'install SomePerlModule'?
It would get compiled for your system, warning you and/or downloading all the required dependencies.
OK Excuse me for being stupid but how is this any different from existing p5-Foo-Bar.rpm?
Rus
Cheap UK and US VPS
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.
CPAN makes it so easy to install perl modules. Why do we need rpms?
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!
I think this is what RedHat and Mandrake users would really like, the trick is probably in keeping all the RPMs up to date. Hope that there is a system that automatically creates RPMs from perl's CPAN module. then all one has to do is "perl -MCPAN -i " and this would download, compile, make a package and install. It would even better to make it package manager independent and add .deb support as well.
Unix, Computers and science fiction... What else can one want in life ?
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.
I'll be honest. I am much more confident with the RPM package manager than the CPAN command you all are saying is so wonderful. Perhaps if I read an instruction book or something...but I don't generally program, so I don't have those books laying around.
I think its a good idea for newbs that can play around with the scripts and hopefully find something that works. Right now I'm working on learning PHP...but am obviously not competent on it yet.
It may be redundant for most of you well learned folks...but then so is that damn gui. I bet you all wish the gui didn't load either...since it is so redundant. :)
Who is this that even the wind and the waves obey Him? Surely this computer must submit also!
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?!
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?(RedHat only)
Oh, only RedHat uses RPM? I thought SuSE and Mandrake, as well as a few others did as well. Shows what I know.
Seriously, though. I use CPAN myself, but CPAN doesn't update the RPM database with dependency & file information and such. What would be a good solution is an optional extension to the CPAN module that allowed it to place files in the RPM database.
"Alcohol, Tobacco, Firearms, and Explosives" should be a convenience store, not a government agency.
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).
Perl packages have been packaged as Debian packages for quite some time--the package and all dependencies are automatically downloaded and they are automatically kept updated.
I'm a little bit confused as to how this is different from Debian's handling of Perl modules? Most any perl package (ie: "Date::Manip") is available as: "lib-perl", like "libdate-manip-perl".
Since they're Debian packages, you get full dependency upgrades, security updates (ie, for CGI.pm) mostly for free, although I'm guessing you're not going to get all the newest / latest / minor / crappy modules. Is that the only advantage?
--Robert
CPAN is banned from the servers I manage, because it likes to sometimes install shit into /usr and overwrite the OS's packaged perl libs. Bear in mind that this is after having edited the config file and pointing to /usr/local as the path to install shit into. Some modules install ok, but others just like to do whatever they want (as opposed to whatever you want). I've made it a rule that nobody with root access is to ever use CPAN to install anything (or else they get to clean up the fucking mess). Since these are all Debian servers, a lot of stuff is availabled in packaged format already, and those that aren't can be easily packaged thanks to dh-make-perl (it's so simple to use, there is no excuse not to.) And anyway, a lot of people already know CPAN sucks, which is why there exists CPAN++, but it's still in developement, or so was last I heard.
Of course, if it's just some user installing modules in his home dir, then CPAN works alright... Otherwise, caveat emptor!
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.)
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?
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
Bad idea.
/opt/perl/perl5.8 while my production 5.6 in running on /opt/perl/perl5.6?
The Perl environment is installation dependant. The location of your siteperl, the C compiler version, the location of your libs, and even the version of your compilor are encoded into the makemaker environment.
The use of RPM to install modules will require that all distributions follow a standard.
What if I wnated to install perl 5.8 on
What do I do if the RPM binary was built with incompatable paths and compilers?
William
---- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(
Oh, only RedHat uses RPM? I thought SuSE and Mandrake, as well as a few others did as well.
They do use different versions of perl. You could say every distribution, and every version of a distribution is different. A package made on Redhat isn't guaranteed to work on Mandrake, and vice-versa. So if this projects makes rpms for Redhat, then that's what it does.
What would be a good solution is an optional extension to the CPAN module that allowed it to place files in the RPM database.
Isn't that what cpan2rpm is for?
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
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.
- Once you use a package management system, you are locked into that system.
- If you use two (or more) different systems, one will not know about the other and you'll end up with an awful mess when you install things with similar dependencies.
- If you manually build and install some software, the package managers won't know about it and you'll end up with a mess.
Instead of using a database of some sort in the package manager, why don't the package managers "search" for the proper dependencies? I know it might take significant resources to perform such a search, but it can be narrowed down by a simple configuration file (likeOnce something like that takes place, you'll be able to download whichever package format(s) you choose at any time, and ideas like Perl Module RPMs will be a good idea.