Seema Alevoor wrote:
> Apache status:
> 
> Open Issues:
> -------------
> - Supporting multiple versions of Apache
>    Should we use
>       /usr/apache2/2.2.4
>    or
>       /usr/apache2.4
> 

/usr/apache2.4 is an option that has been commented on in a previous post from 
Jyri. I quote from his post below.

 > So for a hypotetical 2.4, presumably there'd be  /usr/apache2.4/...
(stuff deleted)
 >IMO, #1 is not right. Introduces a lot of version clutter at the top
 >/usr level for a single component. Let's not.
 >
 >#2 has the argument going for it that it follows previously approved
 >practice (perl, PHP). The pesky detail is that there is already Apache
 >2.0 in /usr/apache2/.



> -- If we are going to support multiple versions, then

>    * package name will change to reflect the latest version.
>      We will follow the php (2007/168) convention.
>      e.g., SUNWapch224d, SUNWapch224u
> 
I think we agree that the Perl/PHP model is a good one to follow.

>    * Other dependents components' (mod_perl, svn, mod_auth_gss, php )
>      build files (e.g., Makefile.sfw) need to be modified to point to
>      the new location.
> 
> 
> - Cohabitation of 32bit and 64 bit Apache installations
> 
> -- If we are going with both 32 and 64 bit installations, then
>    * Other dependents components' (mod_perl, svn, mod_auth_gss, php )
>      build files (e.g., Makefile.sfw)need to be modified to point to
>      the new 64 bit location.
This has to be done only when we deliver a 64-bit Apache HTTP server into SFW 
doesn't it? I think the first phase should be to integrate the 2.2.4 32-bit 
Apache server with support for both the prefork and worker MPMs and the other 
issues that we have reached closure on in this forum. IMO, the 32-bit/64-bit 
issues (for Apache and its downstream modules) can be addressed after that.


> 
> - Supporting SMF way and/or non-smf way of starting Apache
>    This will decide where the property to choose multiple MPMs
>    should reside.
> 
> -- If it is only SMF, then we will use SMF property
>    else, we need to have it in a different file which will be
>    used in both smf and non-smf mode.
>    envvars cannot be used as it is under /usr .
> 
I believe the answer is both - SMF and apachectl.

Arvi

Arvi

Reply via email to