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)
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...
OK Excuse me for being stupid but how is this any different from existing p5-Foo-Bar.rpm?
Rus
Cheap UK and US VPS
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.
Two things:
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.
--
Use Vobbo for Video Blogs
(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.
I've set up a little system to do this. I install all modules to /usr/local/perl (PREFIX=/usr/local/perl LIB=/usr/local/perl/lib). Each module has a file called .packlist that contains all files it installed. I wrote a small script that parses these .packlist files and shows what modules are installed, and optionally lets you delete them. It's quite handy doing things this way.
I've pasted the program at http://rafb.net/paste/results/a2695697.html. 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!
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.
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.
--
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"....
How hard is it to install CPAN modules in the first place? This seems like a solution without a problem to me.
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.
He's exaggerating, but he has a point: CPAN is a *much* better
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.
Cut that out, or I will ship you to Norilsk in a box.
> So once you get past that hurdle, I find the worst part about CPAN
> 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.
Cut that out, or I will ship you to Norilsk in a box.
The problems occurs because software developers are not doing any packaging but the distributors are.
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.