Jyri Virkki wrote:
> Seema Alevoor wrote:
>   
>> Resolved Issues:
>> ------------------
>> - Moving libexec dir from /usr/apache2 to /var/apache2
>>     
>
>   
IMO, it makes sense to keep the libraries and modules under 
/usr/apache2. As you rightly mentioned below, intended purpose of 
/var/apache2 should be to contain htdocs related stuffs.
> /usr/apache2/libexec/ ships containing all the mod_* binaries (shared
> libraries) provided by the distribution. That kind of content is
> typically in /usr. After all, we don't expect these binaries to be
> modified at runtime.
>
> In fact, looking at a snv_72 installation, I don't see a single shared
> library under /var so there is no precedent for libs in /var AFAIK.
>
> As I understand it, the use case is the -i option of apxs, which
> autoinstalls the compiled module into the libexec dir.
>
> (Using -i is not required, one could copy the .so anywhere and point
> at it from the config file.)
>
> Creating a new use case for /var and shipping several dozen shared
> libraries there seems like a fairly big hammer just to accomodate an
> assumption built into apxs -i
>
> What other options exist?  
>
> - Modify apxs -i to write elsewhere, in a location suitable for
>   per-user/per-zone write access.
>   
-1. Why should we allow per user / per zone . This is not what -i option 
is intended for. If a customer wants to compile a module on his home 
directory, he can do this by
apxs -c -o ..

apxs intended purpose is to allow some one to compile and install the 
bits under apache's modules (libexec in our case) without he performing 
it in 2 distinct steps. IMO, we should keep the tradition. Non root user 
will always need to perform the 2 separate steps.
If we special case for -i , then what will happen to '-A' , will be 
removing that option as well ?
> - Don't support -i, instruct users to point at their .so from the config file
>   [this is less desirable, but I list it for completeness]
>
>   
-1. This is a very well known option. We should not be removing this.

thanks
sriram

Reply via email to