I agree. This is what I do.
Actually, this is quite a sane way of doing things.
Rather than have software packages all intermingled, putting them each in their own carefully versioned directory makes a lot of sense.
Here's how I work things:
/pkgs/packagename/packageversion (ex: /pkgs/apache/1.3.19/)- This is the --prefix of any installed package. As far as the
package is concerned, this is where it lives. All binaries and static files go here. This directory can be copied between hosts of the same OS and platform without disruption.
/pkgs/packagename/current - A symlink to what the sysadmin deems is the "current" version of a package. ex: /pkgs/apache/current -> /pkgs/apache/1.3.19/ .
/data/packagename (ex: /data/apache/ )- This is where any host-specific or changable data goes. Configuration files, log files, state files.. They all go here.
/u - This is a symlink soup (ala Stow, Depot, or-- what I use-- pkglink). /u/bin/gcc -> /pkgs/gcc/current/bin/gcc.
Advantages: I can change the current version of a package available to my users by moving the current symlink. If things break, I move the symlink back. Using cfengine to manage the current symlinks gives me revision control over all package versions. If I bless a package as current, yet one user still wants to use an older version of the package, it's still there, they just need to put /pkgs/perl/4.036/bin in their path instead of using the /u/bin/perl symlink.
Disadvantages: Commercial and prebuilt software doesn't always allow a person to specify install location. This pollutes the /usr directories (which I want to be positively static) and can be quite difficult to shoe-horn into a /pkgs format.
If anyone would like to talk about this, my email addr is firstname.lastname@example.org.