While this post starts out with the classic "compile/install your own Perl" line that most other scripting language upstreams spout, it later reverts to the sensible position that distributions just need to provide some package which pulls in the full Perl distribution. That seems much more reasonable, and in fact most distributions do this. Debian provides the "perl" package for a full Perl distribution, and the "perl-base" package for the small subset that the core system needs.

Also if the base system installation requires Perl or another general-purpose dependency, the distribution needs to keep the two forever separate.

The point of distribution packages once was that they would allow for easy updates of your environment without you having to go through the hassle of self-compiling whenever an update (security!) is required and to auto-install dependencies as needed.

But as time went on, the distribution packages became more useless for users and now the recommended practice is to practically leave the distributions packages alone and recompile everything you need (losing the advantages of free security updates).

Ruby, Python and now Perl.

It's not just the programming languages. It's also about users wanting latest versions of their day-to-day software. New Firefox comes out? Wait 6 months and update the whole OS to get it.

Maybe it's time for distributions to slim down considerably to the point where they really only contain everything that's needed for the system to run on its own.

All end-user software (with all their dependencies - disk space is cheap nowadays) would then be installed directly from the vendors - as it's done on every other OS on the planet.

> All end-user software (with all their dependencies - disk space is cheap nowadays) would then be installed directly from the vendors - as it's done on every other OS on the planet.

First of all, by "every other OS on the planet", you mean "the other two major desktop/laptop OSes", as opposed to all the major smartphone OSes where you normally install packages provided through a standardized packaging system.

And second of all, no, let's not switch from a system where every package has a nice uniform install process with automatic dependency handling to one where every vendor has their own "unique" way of doing things.

I'd argue that the various magic scripting language packaging systems exist to handle the OSes without sane package management, meaning OS X and Windows. Those languages wouldn't need gem, easy_install, or cpan if they could always count on apt or rpm. But once the scripting languages implement their own packaging system, it becomes painful to integrate with the distribution packaging systems, so they just say "screw it, ignore the distributions and install it yourself".

And you'd be wrong. For many languages, it is simply not feasible to rely on the OS maintainer to update repositories in a timely fashion.

EDIT: Also, in practice, many applications have a dependency on a specific older version of a library.

I'd suggest s/languages/distributions/. Nothing stops a distribution from updating packages immediately after updates occur upstream, and many distributions do. If a distribution lets their packages for a language or particular module get out of date, report a bug. If the problem persists, sure, recommend that people install their own copy (or switch distributions), but don't automatically assume that no distribution could possibly keep up with your language.

> Also, in practice, many applications have a dependency on a specific older version of a library.

Consider improving your language to have a sensible shared-library versioning system, such as the SONAME system used for standard C-like shared libraries. (I hesitate to call SONAMEs entirely sensible, but they certainly solve the problem you mentioned.)

In any case, consider fixing your application to work with the latest version, rather than delaying the inevitable.

That's not what distribution packages are for. The point of distribution packages is to run other packages in the distribution written in that language. That doesn't mean your own app should use the distribution package, unless you're planning on shipping it with your distribution.

For example, Debian ships with Perl because most of Debian's toolchain is written in Perl. That means feature updates of Perl carry risk with little benefit; the packages work fine with the old version of Perl, but new versions of Perl may deprecate features that they're using. So you can't just upgrade Perl because you want to; your OS won't boot anymore if you do. If you have your own copy of Perl for your application, you can upgrade it (and required modules) whenever you want, and your OS is unaffected. You derive more benefit from newer Perls than Debian does, because you are working on your Perl app every day. Debian's app already works, and maintaining stability is more important than having access to new features.

You're drawing a distinction between "apps" for users and "packages" that users don't directly use, and you're drawing it in a place that is not traditional for Linux. When someone installs Amarok (or finds it pre-installed by their distro) they expect to find a music player they can use, not something that only supports the music player needs of the distribution. In Linux, Perl isn't any different from Amarok. It's an "app" that many users understand and use directly. The packages you get when you install Perl using yum or apt-get are very much intended for users, unless Linux distributions want to depart from history and start treating programmers as second-class users compared to the "normal" users who would use a music player but would never use a programming language. If vendors need their own ancient Perl distro to support their toolchain, that's their problem, and they should figure out how to accomplish that and still give users a usable, up-to-date Perl.

Amarok can do whatever you want it to, because plugins install in your home directory. Never in the course of using Amarok do you affect the system's view of what Amarok is. This is now how people treat the system Perl install; they "sudo cpan -i ..." and end up upgrading modules that the rest of the system depends on. Most of the time, this works fine, because most authors are very careful to maintain backcompat. But sometimes, it doesn't work that way, and now your system is broken.

Using your own Perl gives your application 100% control over its environment, and that's how you eliminate the unproductive task of fixing your servers (and workstations) all the time.

This is why I love Arch Linux. The core installation is super slim, it's just the console, a few utilities, the package manager and you. From there, you can choose exactly which software you want and always get the absolute latest stable version.

Arch doesn't have the concept of OS versions and upgrades - packages are updated all the time and you can choose exactly how often you update as well as whether you want to update just a few packages or all of them.

It might not be a great choice where rock-solid stability and thoroughly tested software is required - this is where distros like Debian shine. For everything else, Arch serves perfectly.

Packages are great! Installing and updating many applications on Windows can be a major PITA.

The only problem, as I see it, is that vendors sometimes fail to keep their packages up-to-date. Until recently, Perl on Redhat lagged 8-9 years behind!

All end-user software (with all their dependencies - disk space is cheap nowadays) would then be installed directly from the vendors - as it's done on every other OS on the planet.

I run Debian/XFCE, for two main reasons. One is proper focus-follows-mouse support (why I stopped using Gnome, well before they started their current "look like a designed-for-touchscreen shell" insanity). The other is that I can use apt-get/aptitude to install just about anything, whenever I want (why I don't just use Windows).

You might notice that that second reason is being copied by the smartphone people with their app stores.

I used Ubuntu 10.04 (the last LTS release) until this Sunday when I upgraded. And I wanted Mono, but Ubuntu Lucid (a less than 2 years old version) comes with Mono 2.4. And seriously, tons of improvements have been made between 2.4 and 2.10. For OS X you just go to mono-project.org and download / install the latest package. That's it. No distribution upgrade necessary.

For Ruby the development in Ruby-land is so fast that trying to bundle the latest JRuby or Rubinius would be a losing battle. And you also need packages installed only for the current user, if only because devs constantly experiment with beta-quality libraries and major versions have a habit of breaking backwards compatibility. How are you going to solve that with DEBs or RPMs?

And you could say that Linux distributions shouldn't have versions and just upgrade stuff as soon as they are available. Well, as someone who lived for several months with Debian Sid, I can tell you that's not such a good idea.

Mono is a special case, because quite a lot of apps which Ubuntu requires to work depend on it. If you swap out the system Mono, many bets are off. However, the usual way to handle this situation is a project-specific repository. If the upstream supplies an apt repository, or pushes to a backports repo like badgerports, then you can install just the version you want without upgrading the rest of the system.

> For Ruby the development in Ruby-land is so fast that trying to bundle the latest JRuby or Rubinius would be a losing battle. And you also need packages installed only for the current user, if only because devs constantly experiment with beta-quality libraries and major versions have a habit of breaking backwards compatibility.

That's precisely what RVM is for.

> How are you going to solve that with DEBs or RPMs?

You're not, and shouldn't try.

> And you could say that Linux distributions shouldn't have versions and just upgrade stuff as soon as they are available. Well, as someone who lived for several months with Debian Sid, I can tell you that's not such a good idea.

Looking in from the outside, it seems to work for Arch.

This isn't 2002. Give me an example that was "hell-like", and I'll show you misusing your package manager, or misunderstanding what the purpose of a package is.

> And you also need packages installed only for the current user, if only because devs constantly experiment with beta-quality libraries and major versions have a habit of breaking backwards compatibility. How are you going to solve that with DEBs or RPMs?

The whole point of updates within an operating system release is stability. You develop for a specific version of the distro release. Then a new distro release comes out and you switch to that. You can even upgrade between distro releases.

So your development model doesn't fit the platform you are using (or you need to make your own rpms).

Still, take a look at Relocate in rpm, or Overlay in Gentoo.