>> For perl modules, I use RPM::Specfile. I have hacked the (included) cpanflute2 to build packages optionally and get dependencies right, and all my perl modules are rpm packages. Which means that I have source and binary (or noarch) packages of them, which means ease of rebuilding. Of course I check every time the existence of a perl package in the Fedora repo, because I'm a lazy boor. And that's just the reason I didn't hack into it the 'follow' mimic of cpan... but then, that's the most time consuming lack-of-features. I guess I should implement that 'follow option', if it hasn't been done already - to just type in cpanflute2 Module-Foo.tgz or cpanflute Module::Foo and get a cup of coffee while it is installing the whole bunch of deps.

Interesting, I'm going to have to do a little spelunking and noodling on this. I definitely need a more robust deployment system

>> Next, PHP vs. Perl. That has long been discussed, and the only bit I'll add to it is the following observation: perl is multipurpose, while PHP isn't. It is easy to stuff functions addressing all kinds of needs of a one-domain-language into one binary; it is hard for a multi-domain language to compete here on the grounds of that specific domain. And why should it specialize, anyways?

Completely agree, except for the one niggling issue that I think Perl + Mason (or add your favorite template/web technology here) actually does trounce PHP, without trying too hard. The adoption problem seems to be just getting things up and running (examples: new Macbook, hosted environment). The problem seems to be simple choice and packaging. Perhaps this is something people will eventually just figure out themselves and we are seeing a short-term phenomena. But the difficulty in the setup just stops people dead. On the other hand some might argue that this keeps the unwashed masses far from the Monastery Gates.

>> PHP is to perl what orcs are to elves.

The funniest thing I've seen today. I'm going to start propagating this meme...