apache2 location

[Scott Haneda]

On Feb 28, 2009, at 3:55 PM, Ryan Schmidt wrote:
> On Feb 26, 2009, at 07:25, Scott Haneda wrote:
>>> One possible reason we might want separate directories for the  
>>> different apaches (${prefix}/apache2, ${prefix}/apache20, $ 
>>> {prefix}/apache) is to allow simultaneous installation of multiple  
>>> versions. However this is not even possible today; the manpages  
>>> still conflict. We could go to considerable effort to make all  
>>> three ports install into ${prefix} but with version-specific names  
>>> for each file, or we could admit that probably nobody needs to  
>>> have both apache (1) and apache2 at the same time and just let  
>>> them conflict with one another.
>>
>> You lost me on this one.  What conflicts?  Apache and Apache2 share  
>> man pages?
>
> $ port installed apache*
> The following ports are currently installed:
>  apache @1.3.41_0
>  apache2 @2.2.11_0 (active)
> $ port activate apache @1.3.41_0
> --->  Activating apache @1.3.41_0
> Error: port activate failed: Image error: /mp/share/man/man1/ 
> dbmmanage.1.gz is being used by the active apache2 port.  Please  
> deactivate this port first, or use the -f flag to force the  
> activation.
> $

Why does ports care if a man page is shared?  I do not really even  
consider it in use.  Forgive my lack of understanding, and hopefully  
no one jumps my butt on this idea...

Why are man pages part of the process of being registered as  
activated? It is a man page, not a binary.  Maybe man pages should  
just not be part of this entire chain of checks.

Sounds to me, like the best thing to do is just patch the source to  
put the man page elsewhere, so it does not conflict.

Could I, as a port writer, use a system call to simply rm the man  
page?  These portfiles would have to be approved sparingly, and  
cautiously, but in the end, heck it is just a man page.

>> Actually, are there any valid reasons ever, at all, to violate- 
>> mtree, or is this just legacy support?
>
> Yes, there are valid reasons. Some examples:
>
> php5 has a variant +apache (will be renamed +apache_apple) which  
> installs a PHP module for Apple's Apache web server. Apache requires  
> modules to go in a particular directory, and in the case of Apple's  
> Apache, that directory is outside of the prefix. Normally ports  
> would not install things that interact with Apple software, but  
> there was strong demand to provide a PHP module that worked with  
> Apple's web server, so it was provided.

Very cool, I had no idea that was being done, that creates a super  
awesome case where people can get a strong dev box up and running, and  
still use the system prefs to manage their apache, very cool.

This also solves OS X Server where it was weak in php support, as in  
most cases, OS X Server only really fails on that front.

> tuntaposx installs a kernel extension into ${prefix}/Library/ 
> Extensions which is not a directory we've included in the mtree thus  
> far.

In the case of a kext, I would be inclined to have a different  
message, as these are much more prone to system issues.

> macfuse installs a new filesystem for Mac OS X which has to go into / 
> System/Library/Filesystems.

Yeah, I have no idea why I did not think of this, much like I am sure,  
if there is a port for ZFS, it will have to violate mtree all over the  
place.  Thanks for the explanation.

>> This solves it for me for the time that these warnings are going to  
>> be around. Of course, I believe the goal should be no warnings,  
>> etc, but where there must be, a wiki page, short and then long  
>> description, both for user and maintainer, is perfect.
>
> We could start creating some of these wiki pages by breaking things  
> out of the FAQ. The first one that comes to mind is the checksum  
> mismatch entry. As for where in the wiki these pages should go, I  
> don't even think we need a prefix; they can just go at e.g.
>
> http://trac.macports.org/wiki/ChecksumMismatch

Sounds valid to me.  Do I need special access to the wiki to  
contribute?  I can help here, and I can certainly make the time.   
Having the wiki pages ready for a update to MacPorts would be nice.   
Then it all just falls into place.

If someone can seed the wiki with a list of names for which need the  
detailed warnings, I am more than happy to start entering in stuff,  
and then having others edit it to final form.
--
Scott

* If you contact me off list replace talklists@ with scott@ *