On Wed, Jul 23, 2008 at 9:23 AM, James Carlson <[EMAIL PROTECTED]> wrote: > Fredrich Maney writes: >> I've always advocated that software should be compiled/built in >> version specific directories with links from the standard locations to >> the current version, like so: >> >> link /usr/local to /opt >> place Apache 2.2.8 source in /opt/apache/2.2.8-src >> compile and install it into /opt/apache/2.2.8 >> link the appropriate binaries into /opt/bin/ >> >> It does, if you keep multiple versions around, sometimes become a >> little complicated, however it does allow for very quick upgrades and >> rollbacks in the event of problems. > > I'd find that hard to advocate by itself. Managing multiple versions > is something that the software packaging system ought to provide in a > consistent way across the system, rather than just asking each > software developer to roll his own private solution.
I have not yet seen a packaging system that could handle multiple versions of the same package being installed and in use at the same time while also managing (correctly and sanely) dependencies, configuration files, logs, etc. I like being able to not only minimize my outages for an upgrade/rollback, but also to be able to do things like have Apache 2.2.8 running for just the external facing sites/networks, while having Apache 1.3.3 running for just the internal sites/networks on the same box, serving (at least some of) the same content pages. > There are other important considerations besides the directory name, > including common configuration files (across versions), address space > pollution by multiple-version libraries, and potentially forcing > dependent projects to deliver per-version bits for each dependency; a > geometric explosion. > > I think versioning is a much harder problem than just directory names > and symlinks ... if it's done well. Understood and agreed. Hence the "complicated" comment. However a logical directory structure makes things quite a bit more simple for a packaging system to handle. fpsm _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
