Add that some languages are actually hostile to any OS maintainers trying to package anything, like Ruby with its gems and RVM.

"(The interests of languages, developers of language packages, and distributions are basically all at odds here.)"

But what about the interests of the users and customers? They need (not necessarily in priority order)

1. Security fixes 2, Bug fixes 3. New features 4. A mechanism for having a voice in product direction.

I run a Fedora Linux desktop, but not every Perl or Python or Ruby or R package that I want to use is packaged as an RPM. This causes versioning nightmares for me, the user. I doubt if it's significantly better for Ubuntu, openSUSE or any other distro.

From my point of view as a developer, that last bullet point cannot be overstated.

For instance RedHat’s name in the Perl community is forever tarnished as the distribution that repeatedly shipped significantly broken /usr/bin/perls due to their insistence on patch-backporting fixes and sometimes features from later versions of Perl, an enterprise at which they had… irregular success. Other vendors have stripped out modules or the documentation from their main perl package.

As a result, over time, a culture of distrust toward the vendor-provided perl has grown. The attitude is that if you want predictability, your install your own local language environment to develop with or to deploy to, whereas the vendor-provided perl is seen as an opaque part of the OS which is maintained to satisfy the needs of vendor-maintained OS packages that need perl – not for the user’s application development needs.

Now RedHat have been good for a long time, and no other vendor has screwed up really badly in more recent times. But the culture persists since people soon realised that it’s also helpful to be isolate different Perl applications from each other. (An upgrade to a dependency used in several of your apps may cause conflicts in one of them but not the other, and you will likely want to not be forced to upgrade them in lock-step – because the consequence of that is getting stuck on ancient versions since nobody dares to upgrade for fear of breaking some other team’s code.)

Also, Perl’s release schedule has picked up steam into a steady rhythm in the last three years – which not all OS vendors have started running along with quite yet. 5.8 still has a huge install base only approached by 5.10, though the latter seems to be starting to fall off. So if you want to use a recent perl, or sometimes even just a perl younger than the iPhone, you have to install one yourself.

And all of these experiences generalise directly to any other source-based language.

And in thinking about this further, the issue it really comes down to is the package source/authority:

The reason for the friction experienced by Jane Perl-Girl is that she will often want to use things from CPAN – which get written on any number of systems and are not necessarily optimised to work with whatever particular OS (and version). But they tend to be written by people who use modules directly from CPAN, which means that in aggregate, software on CPAN tends to work best with other software on CPAN.

Likewise the vendor’s interest is to patch that perl and the modules in it in whatever way is necessary to make that perl and those modules work for the other packages the vendor is maintaining.

So if you want to use modules directly from the CPAN, you’ll want to do this on a perl downloaded from CPAN, using other modules directly from CPAN; whereas if you want to use packages that require perl modules, you’ll want to install the module packages provided by your OS vendor.

What this means to me is that this is that this multitude of package managers is not just a question of the situation at hand giving rise to certain pragmatics, but fundamentally inevitable/necessary.