No. The first time it was equal parts arms race, chest-beating nationalism, and 100 billion dollars.

Last time my project got mentioned on Slashdot, I saw around 50,000 additional downloads for that release.

So even if it's one-shot, that one-shot can still be big.

If I worry about whether you will ever finish the book, why would I bother paying for the first chapter (or even bother starting to read the story at all)

A 37gig SQLite database, containing every testing report ever submitted to CPAN Testers...

The people that create the language aren't the same people that look after the packaging system.

We've found that the sanest mix is to install the core OS packages that don't suck, then do a CPAN install of the rest to some /opt/project-cpan path.

That stack of 10 or 20 dependencies turns into a single project-cpan RPM/Deb, and the application just adds the /opt/project-cpan to it's include path.

Now granted, there's no standard tools for doing that... yet.

Ah! The workaround is...

1. Use CPAN to upgrade itself.

2. Install everything else.

Or, more recently, just

cpan App::SVN::Bisect

Is the parent a bad post, or a good troll?

Some responses if I may...

Perl dependencies are specified by class name, not by distribution package name. So (theoretically) as long as there's a way to resolve a class to a file (which is standard) and thence to an operating system package ("which package contains file X" shouldn't be that hard) then there's no reason that Perl package dependencies can't be mapped down into distro package space.

As for the versions, 1.30 is more correctly more recent than 1.2437, because the CPAN turns multi-part versions 1.23.1 into decimals using an admittedly icky triplet system where each part of the multi-part is normalised into three digits.

1.2437 is a normalised version of 1.243.7. Downstream distos have implementations of this logic available to them in places like CPAN::Version. But yes, it is a bit weird for the newcomer. It's the price of 5-10 year back-compatibility, alas.

As for Perl 5.10, almost nothing on the CPAN will depend on it. The current recommended back-compatibility targets are Perl 5.6.2 for low-level or toolchainy stuff that needs a decade of back-compatibility, or Perl 5.8.5ish (around 5 years) for regular things (which is the first version where Unicode became bug free and universally usable).

So Perl 5.10 is having almost no impact on compatibility, and won't for at least another couple of years.

The CPAN installer hasn't had the Perl auto-upgrade bug in several years...

I offered to port the CPAN to Python about 6 years ago as a gift from the Perl community, and I repeat the offer every now and then.

It usually goes down as well as you might expect when someone from Python people hear the word "Perl" anywhere in a coversation :)

In the mean time, we've quite successfully ported and adapted the CPAN model for JavaScript with OpenJSAN and (more recently) for C with The CCAN (run by Rusty Russel).

Both of these are arguably more sophisticated than Python's packaging, although of course both of them are still down in the range of 100 packages.

> Half right. A programmer's job is to take an idea and express it in a way that both computers and humans can understand. If only a computer can understand it, you might be a Haskell programmer.

There, fixed that for you.

That every sysadmin on the planet pretty can learn Perl means there must be humans in that group somewhere.

Now a language you have to be a mathematician to learn on the other hand... :)

Many authors of open source software (particularly smaller cases) will only ever experience a limited range of situations, which will influence the design.

People who have only ever worked in large corporations will make things overly complex to configure, people who only work in startups may undervalue documentation and reporting (I'm making hugely vast generalisations here).

One valuable thing you can contribute is your experience using that software in government. You understand the nature of government and its priorities probably a lot better than the original developers.

Contribute bug reports, feature requests, and commentary (ideally into proper bug/feature tracking systems) that address specific areas of interest to government.

Open Source developers love it when they hear their work is being used in interesting real-world scenarios, and your experience with government can suggest directions they might otherwise not have considered, or have underprioritised in the past.

Apart from the tea lady role, the other good thing about having management around is that when the shit is hitting the fan, at some point you are often going to need to do some rather unconventional and similarly scary things to fix it.

Having the manager a "Hey boss" yell away means you can at least get "approval" for whatever it is straight away. Now the plebs can't be scapegoated or blamed for solving it by doing something against policy. Granted, it would be nice if that wasn't needed, but the fact you CAN get approval for crazy things quickly means the people fixing the problem are less likely to hesitate due to fear for their own skin.

In Australia we buy oil from the Singapore exchange, which STILL isn't in Australian dollars.

So even using that market, the need for translation is still useful.

Or what about the gold price, or Chicago exchange coffee prices...

The problem here is not the question, it's that the answer is illogical