Now I'm thinking about package management

I sort of want to build a package manager for Solaris and other ancient systems, to make it easier to bring up software that I need on there (so that I only have to go through the effort once and then can install it on a second or third or fourth Sun computer, too)

The problem: I am utterly unqualified

Imagine I want to run GIMP 0.54.1, which requires libjpeg v5 or v6 and libpng 0.71

I also, on the same system, want to run the latest version of links, which requires libpng 1.4 or newer

Now what

Obviously, if it's just these two programs, the solution is "compile both versions of the dependencies and put them in different directories"

But now imagine that there are a lot more programs...

Maybe the laziest solution would be to have two directories /opt/ancient and /opt/new where one has stuff like GIMP 0.54.1 from the 90s and the other one has stuff like the latest version of Lynx

Maybe the best way would be to group by decade
Most softwares have dependencies that are approximately as old as them

So if I do something like /opt/myPackageManagerName with the subdirectories 2000, 2010, and latest, that could work...

Actually, maybe a more general solution would be, if I need multiple versions of e.g. libjpeg, to mkdir:

/usr/local/lib/libjpeg

with the sub-directories:

v5
v6
v9
latest -> v9

Though the path handling would become really annoying...

@vaporeon_ you ever hear of the slashpackage convention? or, somewhat similarly, what GoboLinux is doing?