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."
Machines have less problems. I'd like to be a machine. -- Andy Warhol
seems a little wasteful.. (Score:3, Interesting)
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...
Existing RPM's (Score:3, Interesting)
Rus
Re:CPAN installs dependencies on the fly (Score:4, Interesting)
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.
Re:Huh? (Score:4, Interesting)
1) CPAN isn't flawless: yesterday, I tried using it to install File::Temp and it tried upgrading perl from 5.6 to 5.8. That simply isn't the correct thing to do, under any circumstance.
2) Having used FreeBSD, which has perl modules in the ports/package system, I can absolutely say that it's a nice thing to have. Being able to pkg_add a perl module in half a second, no compile time, no dependency hell, it's a good thing.
Re:CPAN installs dependencies on the fly (Score:3, Interesting)
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.
Re:Uninstall? (Score:1, Interesting)
I've pasted the program at http://rafb.net/paste/results/a2695697.html. [rafb.net] It's horribly hacky in part because I didn't care to figure out pod parsing modules and also because I just sat down and wrote it without thinking about it.
You'll do better to write your own that doesn't make so many assumptions, but it's at least a starting point.
PS: don't blame me if it kills your computer. Also, I don't know how long this paste site keeps pastes, so if that URL is broken, well, you shoulda gotten here earlier!
Re:perl with RPM lovin' ? (Score:5, Interesting)
It didn't take me too long (and hour or so, maybe) to get a minimal server-ready RH8 installation down to 300MB. If I removed the documentation under /usr/share/doc and a few other bits, I could probably get that down to about 222MB (this figure includes Perl and a bunch of commonly-used CPAN modules, BTW, so it's actually a trade-off between "minimal" and "actually-useful" ;-)
You can find the kickstart file in this thread [google.com].
There are too many cascading dependencies. You would be better off compiling the stuff you want statically. You'd save space.
Yeah, and then when a security problem is found, you end up having to re-compile the lot. Eww.
--
Nope! He ain't exaggerating!! (Score:1, Interesting)
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"....
Re:Huh? (Score:3, Interesting)
It isn't very hard to do "./configure && make install" either for normal software, yet we still haver package managers?
Why, you ask? Because we want to be able to uninstall stuff as well, because we want to have dependencies and because we want everything relating to software installation be handled by one program (apt or yum, for example).
So, not only are they converting Perl modules to a format they don't really need to be in
Perl modules are libraries and they need to be packaged just as much as C/C++ libraries!
but they're making the thing harder to use than CPAN is already.
Simply untrue, why would "apt-get install foo-bar" be any harder than "perl -MCPAN -e 'install foo::bar'" or whatever. Actually, Perl/CPAN version is bit harder to use.
You may not see it, but there was a problem and this is exactly the solution that was needed.
Re:perl with RPM lovin' ? (Score:2, Interesting)
package management solution than plain vanilla rpm. There are also
tools that go on top of rpm and help somewhat with this, such as
urpmi, but as yet none of the package repositories are anywhere near
as robust as the CPAN system of mirrors. I have often wished that
non-Perl packages were available via CPAN, though I certainly
understand why they're not.
Re:Huh? (Score:2, Interesting)
> is that some packages which everyone uses like mod_perl, DBI, and
> DBD::mysql fail to install unless Apache was compiled the correct
> way and currently running, or MYSQL is running and allows some
> bullshit nameless user to access all databases (!)
For DBD::mysql, I think you can say no when it asks if you want to
test. mod_perl is a problem if you don't have the Apache sources
installed, and IMO the correct solution is to include Apache on
CPAN and make mod_perl depend on it. After all, Apache is basically
a really big XS module, right? Oh, that same approach could be
taken for MySQL and other packages that, while they aren't part of
perl per se, exist primarily to be used by perl.
Re:perl with RPM lovin' ? (Score:2, Interesting)
If the basic packaging system was used by developers too this would not be a problem.
Of course, establing one standard will take some time. Especially since different distros package things in slightly different ways.