Perl Modules as RPM Packages 207
libertynews writes "KPLUG President Kevin Pedigo has just announced his latest project -- RPMPAN, an archive of CPAN Perl modules in RPM format, generated nightly."
No amount of careful planning will ever replace dumb luck.
Huh? (Score:5, Insightful)
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.
What exactly was wrong with... (Score:4, Insightful)
It would get compiled for your system, warning you and/or downloading all the required dependencies.
Re:Huh? (Score:4, Insightful)
Need the reverse of this (Score:5, Insightful)
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.
Re:Huh? (Score:3, Insightful)
CPAN == RPM for Perl mods (Score:2, Insightful)
It solves a problem (Score:5, Insightful)
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 [studentplatinum.com]
Good idea.. (Score:2, Insightful)
Re:CPAN == RPM for Perl mods (Score:5, Insightful)
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.
Uninstall? (Score:4, Insightful)
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).
-1 Troll (Score:5, Insightful)
Uh, I'd just do:
What's the problem again?Re:Need the reverse of this (Score:3, Insightful)
Sounds like a solution to your problem.
Alternatively, there's always --nodeps if you're sure.
Perl on Debian (Score:2, Insightful)
How is this different from Debian? (Score:2, Insightful)
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
Good idea! (Score:5, Insightful)
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:Huh? (Score:5, Insightful)
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
Re:What exactly was wrong with... (Score:5, Insightful)
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:perl with RPM lovin' ? (Score:5, Insightful)
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:Huh? (Score:2, Insightful)
Except that there need to be different rpms for RedHat, Mandrake, SuSE
Really, the cpan setup keeps track of its own dependencies, and gives you flippant comments like "yep, it's a nice idea to include this if you actually were to wish to use that" to boot. No rpm setup can get close to that.
Perl Modules as RPM Packages (Score:2, Insightful)
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
Re:CPAN installs dependencies on the fly (Score:3, Insightful)
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?