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
Christ!
Thus making it already a superior way to install Perl modules. Not to rain on a parade and this may be useful for systems where there is no CPAN (can't imagine WHY though), but where is the benefit of this over CPAN? Perhaps this will make it easy to deploy with no network connection? I'm just lost here.
OK, so this is predicated on the idea that RPM is a better package manager than CPAN...and that your perl setup is pretty much identical to redhat's. Since many (if not most) perl modules don't have c extensions, a binary distribution isn't really that useful, is it? I mean, perl -MCPAN -e shell; install foo works pretty well, and will download and install dependencies for you.
I guess I'm thick or something, what am I missing here? What's the point?
What a strange bird is the pelican, his beak can hold more than his belly can.
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?
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.
There's actually nothing wrong with it. CPAN has solved all dependency and installation problems very well.
Problem is that with current package managers you have to mark some dependencies.. and you need mark them at least for some special Perl modules too since there are some Perl programs that are important enough to be packaged.
Using this RPM program (or in Gentoo g-cpan.pl) you can install these packages so that all the dependencies are satisfied and they can be marked to be updated when necessary (you get that at least in Gentoo) etc.
You get the power of Perl CPAN + power of packages. That's a lot of power.
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
Never Mind
Uh, I'd just do:
What's the problem again?Well, Linux has a great deal of separate functionality that you need to learn the ins and out of. Perl's CPAN is just another one to learn. The process of constantly learning is training that is invaluable. Once you've used apt, or emerge, or portage you end up scratching your head anytime someone mentions using rpm. Perl's CPAN isn't difficult but I imagine the fact that these RPMS are binary versions are what make them good...less waiting for the IT professional with a Job to do.
I suck.
must learn more.
Honestly, I know my ins and outs with microshaft, can even realize some of the tools for admin in linux are FAR superior and EASIER to use...and free...but that doesn't mean that I know about ALL the Linux tools either.
I think this is a valuable tool for those of us out there that don't exactly have a 'full toolbox' like the rest of you. :)
WARNING: BAD ANALOGY TO FOLLOW:
Real carpenters and working men may have several hammers that they use on different things, but the starting 18 year old kid...yeah, he just buys the middle range hammer at the hardware store and beats the s#@t out of everything with it.
Who is this that even the wind and the waves obey Him? Surely this computer must submit also!
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.
The problem normally is simply compiling the damn module on your distro, wrong version of compiler or libraries or similar.
n lo ad.plex?id=ActivePerl
But in that case, we got ActivePerl,
if only they had all the packages working fine:
http://www.activeperl.com/Products/Download/Dow
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
Second, there are LOTS of dependencies between perl modules and system libraries. Often, you'll have the runtimes for the libraries you need, but not the archives, so you can't build the module unless you download a bunch of -devel RPMs.
And, it sure is nice to do "rpm --verify" and verify that your RPMs are untouched.
Get rid of everything Micro and Soft: Buy Viagra and/or Linux
CURSE YOU! Curse you all to hell. The one thing preventing global domination has been removed. ARRRGGGHHH!
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?
Perhaps in case you want to uninstall a module. Go ahead, show me how CPAN does that :)
Finkployd
wrapped up in an installer that R eads P rogrammers M inds. HOW WONDERFULLY SUBLIME
OH THE SHAME I fell off the wagon and use sigs again!
I can see it now, "oops, one simple bug shut down the whole internet via a perl module RPM"
It's so hard to keep track of where all those freakin' perl modules end up, with all the site_perl and vendor_perl and 5.8.0 and three or four different places where the aforementioned directories are.
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
It's like, let's take the two package management systems I hate the MOST and combine them.
Uggh..
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
cpanflute foo.tar.gz ; rpmbuild --rebuild foo-*.src.rpm
[
Right man where the heck are we getting the ebuilds for the stuff. Cant have some other distro have this and not us.
BSDPAN is dying.
The most annoying thing is that rpm will not recognize or even check for anything that has not been installed by rpm -- if it ain't in rpm's database, it doesn't exist; which makes it practically worthless if you've got items installed by downloading your typical tar.gz file and doing the ever popular "configure; make; make install".
Relying solely on rpm is like being forced into a Microsoft style we-own-you way of life. Hmmm...now that I think about it, maybe the "r" in rpm stands for "redmond"....
Nope! He ain't exaggerating!
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?
This is great, for a while I have been using cpan2flute which comes in an RPM from freshrpms to build my own RPMs from CPAN for my RedHat boxen, and this will save me from doing that :-)
Will there be an apt repository? I hope so :-)
Also will it be able to cope with ImageMagik -- probably the hardest Perl module to get working in my experience...
Check out MKDoc a mod_perl CMS
I've never wanted to uninstall a Perl module.
aka ANALPLUG
"It might be harmful if you do something stupid with it, therefore you mayn't do it at all" is not proper unixy design IMO.
/usr/lib/libfred.so.1.1 which satisfies requirements"
Your scenario describes one stupid way of shooting yourself in the foot, but it's hardly a unique one. Other similar ones would be: uninstalling with --nodeps, overwriting an RPM with a "make install", overwriting libs with a newer version and "-ivh --force" so as to make new programs load whilst keeping older ones, etc etc.
Basically, it's a problem that won't bite newbies (becaue they use all RPMs with the GUI installer, if they install at all) and shouldn't ought to bite pros (because if they use it, they know what they've gotten themselves into).
Perhaps at most RPM should print a warning: "warning, package fred-1.x was not installed, but found
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(
Maybe it's just me, but RPM format seems to suck. Every time I install something through RPM, it rarely works. And if I go and update or install software from it's orginal *gz source package, it usually fails because the libraries upon which it depends are misplaced or not found. I tried to update Gtk from it's original source (Becuse the version on the Redhat website was quite out of date) and after it was installed, it still detected the old version. RPM's are a pain to deal with, bottom line.
--
Adobe's anti-counterfeiting softw
Hey...I was where you are about 5 years ago and now I'm reasonably proficient. If I can figure this stuff out, there's hope for just about anyone :)
It took me about 6 months to move around comfortably...I've added Perl programming skills, some trivial sed stuff, and various grep and regex stuff to my toolkit over the remaining years.
A friend of mine in college who helped me learn Linux (I already had a little background in Solaris as a user) told me that if you were to graph "knowledge of the OS" on a horizontal axis and "what you can do" on a vertical axis, then on the Microsoft graph, the plot would be logarithmic (you may learn tons more, but you can't do a whole lot more) while on the *NIX graph, it would be exponential (takes a bit of knowledge to get going, but then incremental additions translate to much, much more power).
FWIW
What is your Slash Rating?
Debian User: You might want to apt-get install dh-make-perl. "Description: Create debian packages from perl modules dh-make-perl will create the files required to build a debian source package out of a perl package. This works for most simple packages and is also useful for getting started with packaging perl modules. Given a perl package name, it can also automatically download it from CPAN."
Not every Linux box has a compiler on it. There *are* people who save the massive disk space and time it takes to install a compiler. If I need Time::HiRes on a machine that has no compiler I'm facing a nasty prospect of building it myself on another machine, hand copying it over and installing it. I could also take the time and disk space to install a compiler that will possibly only ever be used for about half a second. Now I can just install an RPM.
More than once I've sworn that there weren't RPM's for all this stuff. I'm happy now, the world got a little better and I didn't have to do it.
Support your local wacky perl project. I do!
set softtabstop=4 shiftwidth=4 expandtab nocp worlddomination
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.
Did anyone actually bother to visit the RPMPAN page? Check out that logo, it's so camp.
mogorific carpentry experiments
First I've heard of yum, just downloaded it from here:t ml
http://linux.duke.edu/projects/yum/index.p
So far, so good.
I dont know , maybe I'm just missing it . But to me RPM is a fairly crappy package management program . The CPAN shell appears to be far supperior , hell it actually works and resolves dependancies . Now I have not used redhat since 7 (except at work were I deal with a hodge podge of systems some redhat , some debain , some misc) , so if rpm has improved vastly please correct me . Otherwise this just seems like a waist o time to me.
this made my morning. I work at a strictly Redhat shop, and I do like RPM ( no flames, please, Debian is great, so's Gentoo, so's FreeBSD, but so is Redhat + RPM ), and perl is an excellent way to get things done quickly.
In the past, I've had problems w/ wanting to use a module, which is dependent on 5 other modules, which is then dependent on 5 more, etc., so I end up building 10-20 RPMs for just 1 module. Which I will have to update sometime in the future...bugger! Which, when under time pressure, generally leads to me writing a replacement for the functionality I needed from that module.
So my life just got easier!
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
Besides all good reasons to have CPAN packages managed as RPMs there is on more people failed to mentioned:
When I ship software to customer on CD, which uses some perl script they expect me to have ALL they need on this CD. Knowing their version of Redhat Linux I can pick and package appropriate CPAN RPMS and be sure that RPM package manager will take care of dependencies.
Besides (beleive it or not!) there are some computers which do not have internet connection. Some people want to be able to install perl software on them.
Yup, same deal for me under Mandrake 9.0 AND Solaris 5.8; tried to install the newer version of Perl. I did exactly what another poster recommended to get Spreadsheet::ParseExcel and ::WriteExcel onto my Linux system -- use another Perl module .src.rpm as a template and change the few things needed to "rpm -ba" the new module. Really pretty dang easy, and since none of these distro folks can agree where things should live (LSB notwithstanding) pretty much necessary to get things in the right place.
For Solaris, I ended up having the sysadmin get the modules installed; trying to do it in a local area always got me the new version of Perl.
Love them perl modules, though!
- Leo
You don't use science to show that you're right, you use science to become right.
Why did they decide to use rpm over debians apt?
Just because I didnt say it that way doesnt mean that it means something different!
Speaking at Defcon 12 - Credit Card Networks Revisted: Pen
>exist primarily to be used by perl
WTF??? The P in LAMP is php, not perl. MySQL is used in so many more environments than perl, take your head out of the sand. Apache also is used by many to host so many web pages of dynamic content not generated with perl but with java, any given cgi language, and on and on.
How language arrogant can you get!?
WHAT THE HELL ARE YOU SMOKING???
I've installed Apache tons of times without support for mod_perl, and let me tell you unless you are doing a LAMP installation you don't want to think about it.
Similarly, there are tons of non-perl apps that use MySQL as a backend for various reasons (usually to supplant huge flat configuration files or logs).
Not everything is webserving, man!
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
What's wrong with:
# perl -e shell -MCPAN
or
# cpan
?
-- @rjamestaylor on Ello
cpanflute sounds interesting. I'm going to have to remember that (and checkconfig, mentioned earlier)
Anything that helps you autogenerate RPMS is useful in my mind.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Spend two minutes looking over the discussion threads attached to this story, and you'll have all the evidence necessary to demonstrate that Linux and most UNIXes are nowhere near ready for the masses.
When so much technical prowess, time, frustration, and hassle is necessary just to install software, it means the OS is poorly architected and lacking coherency.
Windows has DLL hell and other problems, so I'm not saying it's a great example.. but it's certainly easier for most people to deal with. I don't know anyone who has had to manually wrestle with 14 package dependencies just to get a program installed on Windows, do you?
Mac OS X seems close to the ideal, from what little I've read about it. Single filesystem objects that contains everything necessary for a program to run, a sane versioning system to prevent runtime library hell, and none of this nonsense about forcing end-users to wrestle with insane dependency maps just to install a program.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
You said: ./configure && make && make install
> CPAN builds the Perl modules with a
>
Not true. It's
perl Makefile.PL && make && make test && make install
HTH HAND,
ua
Union Yes! Member of Technical Workers' Local 101010
- 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.
duh! :-)
That's the whole point of package management
:-) ) is becoming more popular to the detriment of CPAN.pm... but, whatever, I'd much prefer a package manager in the style of CPAN.pm -- with all its faults -- than one in the style of rpm which causes never ending cuss words to spew forth from the mouths of kind hearted souls....
CPAN.pm does what rpm should be doing.
Although not perfect, It does a way better job -- not only does it notify you of dependency problems, it goes on to solve them -- and if you've installed something without using CPAN.pm, it'll find it -- unlike rpm's braindead system of not recognizing anything not in its database.
I've had problems in the past at installing Image Magick and PDL, but that seems to have been a problem (I think it was in image magick's case) of them wanting you to edit by hand the makefiles/config files which were configured specifically for their own systems -- hopefully they've learned about autoconf by now!
Recently I've had problems with CPAN.pm in installing other modules, I'm not sure if its because of lack of testing of modules before they're being uploaded to CPAN, or because CPAN.pm is getting out of date and that other CPAN installer (I forget it's name
checkinstall sounds good, maybe what's needed is another level of indirection -- rpm and checkinstall should be merged -- in other words, what's needed is for rpm to become more like CPAN.pm. :-)
Automatic package management without the brainded quality of rpm alone...
Redmond Hat Linux?
:-)
The secret has been revealed!
dictionary dot com
CPAN rocks. Why contribute to the ongoing Project Tower of Babel in computer software??? CPAN is already Grand Central Station for Perl on Unix/Linux.
Why are so many people determined to add to the Tower of Babel!!! Enough already!!
HenryJamesFeltus.com
Gee...what ever happened to good ol' ambition and initiative?
No guts, no glory.
using apache to serve documents to people. (imagine that!)
What about people using java servlets? PHP?
What about SSI and makefile maintenance, or more sophisticated CMS systems?
What about using Apache as a proxy server. Media streaming server... server management consoles... etc.
Do any of those common applications require the use of Perl with apache?
No. So just because you think that they go hand in hand, let me assure you that they are seperate entities designed to exist on their own. Why don't you ask Larry Wall if apache is really an XS module? Maybe you should email the Apache Foundation and tell them to start distributing themselves via CPAN.
Hehe.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
This is cool, but the debian way of using apt-get to get perl modules is some much easier since dependancies and rpms don't seem to get along that well.