Love/Hate and package managers
I have a long standing love/hate relationship with package managers.
On one side, you have access to most of the software out there already compiled (presumably by someone who knows and uses the software and therefore is able to choose the proper, most useful, configuration options) and with all the administrative bits (startup scripts, example configuration files) in the "right" place (usually dictated by some standard like the LSB).
On the other all the package managers that I know of (and this is really a cry for help, please tell me of exceptions to this rule) have a Highlander-fetish with regards with package versions: there can be only one.
At any point in time, you can have one and only one version of a package installed it seems. If I have two applications running on some server, and you tested one of them with version X of the package P, and the other with version Y, you cannot have both versions installed at the same time. You have to pick the latest one and hope that backwards compatibility was not lost.
Most people with setups larger than mine that I talk to about this just tell me that "oh, you should split your applications on different servers, easier to manage, profile and tune". That's true, but most small mom-and-pop business don't have or don't want to spend capital to work around limitations on package managers.
There is also a good argument to be made for security. Keeping old versions around and in use is a security risk if the newest version was released to fix a security problems. I acknowledge this whole heartedly, but still, sometimes you know that you are using and old buddy version, but you still need to keep it running for some time, either because you evaluated the security problems and they don't apply to your configuration or because you need more time to test with the new version. We should be aware of the dangers you put yourselves in when you ignore upgrades like that, but you shouldn't be ruled by fear also. Analyze, weight your options, decide. Be rational.
One clean solution is a containers package like OpenVZ or FreeBSD jails or Solaris Zones: one kernel per server, several virtual servers. I admit that I strongly prefer this type of container-based virtualization solutions to the big ones that require processor support for decent speed, like VMWare, Xen or Parallels. I have a strong distaste for waste, and having multiple kernels running on the same metal, although extremely useful in some scenarios, is very wasteful of resources in the general case.
So although I just got a server at the office to have a second round of OpenVZ tests (and I'll probably use it in production for all my servers if I'm happy with them), I still believe that all of this is a big blanket over bad package managers.
My ideal package manager would create a base directory somewhere, lets say /p, and would create a set of directories, taking in account architecture, package name, and package version. For example, you could have perl 5.8.9 and perl 5.10 like this:
/p/i386/perl/5.8.8/{bin,lib,...}/p/i386/perl/5.10/{bin,lib,...}/p/x86_64/perl/5.10/{bin,lib,...}
Also, you could keep the notion of latest using: /p/i386/perl/latest as a symbolic link to /p/i386/perl/5.10. This way other packages can require any version of perl or a specific version of perl.
The PATH environment would be tailored to the specific versions of each package you want. Just include the proper bin/ of the specific version you want. A global /p/${arch}/bin/ could be setup with symbolic links to the package/latest/bin/ files.
Clearly the solution of using OpenVZ is easier to manage today, no need to find or build a package manager like this, but still, I would really like to see it sometime.