Hi Everyone, This of course brings us back to the idea of maybe collapsing the apache directories the way we do with Java, Perl, etc.
As such something like this would work: /usr/apache/<version>/<release> So we would have: /usr/apache/1.3.x/ /usr/apache/2.0.x/ /usr/apache/2.2.4/ Have a symlink called "latest" to the latest version. Dumping 1.3.x may break IPP, webmin, webconsole, etc. I'm not sure if they are using apache2 right now or not. I think we have to keep the versions to a min and decide how many we want to support ( I would say not more than two ideally). Octave --- Ben Taylor <[EMAIL PROTECTED]> wrote: > > The ARC Cases for the WebStack NG Project have been > > submitted for review (and hopefully approval), and i would > > like to ask our community's input regarding two important > > questions which have come up during our discussions: > > > > 1. Should the initial components released for this project > > include the 64-bit bits in the initial Integration ? > > I would think so. Does anyone have benchmarks of a 64-bit > compiled WebStack vs 32-bit equivilents? > > > 2. The currently proposed Apache 2.2.4 integration installs > > Apache in /usr/apache2, thereby _overwriting_ the existing > > Apache 2.0.x. Valid arguments have been made pro, and > > against this approach, with the suggestion that Apache > > 2.2.4 installs in /usr/apache2.2, thereby preserving the > > existing /usr/apache2. > > > > However, this alternate location would *not* alter the > > EOF/EOL timeout announced for Apache 2.0.x. > > I can't imagine anyone who has spent time in the *real* world > would suggest that the apache 2.2.4 replace the existing > apache 2.0.x. They would understand that in many cases, the > consumer would like to be able to "baseline" their existing > apache 2.0.x install vs a new install which may behave differently > than they expect. Having to *reload* Apache 2.0.x because > Apache 2.2.4 didn't work as expected is an undue burden, and > makes it difficult to do a side by side test. In the case of > *replacing* apache 2.0.x, a user would require *2* systems to > baseline, instead of one. > > What's wrong with letting the consumer *decide* when to remove > an obsoleted version of apache? > > > This message posted from opensolaris.org > _______________________________________________ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* ____________________________________________________________________________________ Don't get soaked. Take a quick peek at the forecast with the Yahoo! Search weather shortcut. http://tools.search.yahoo.com/shortcuts/#loc_weather _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org