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

Reply via email to