apache2 location

[Ryan Schmidt]

On Mar 1, 2009, at 03:58, Scott Haneda wrote:
> On Feb 28, 2009, at 3:55 PM, Ryan Schmidt wrote:
>> $ 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.

MacPorts has no special knowledge at destroot time that this is a  
manpage. It treats all files the same.

All files need to be part of the destroot and registered to the port  
so that "port contents" can show them and "port uninstall" can  
uninstall them.

You wouldn't want an older manpage provided with the apache (1) port  
to silently overwrite the newer manpage you already had from the  
apache2 port. These are the kinds of problems having a destroot solves.


> 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.

"man" only finds manpages in the manpath, which is always ${prefix}/ 
share/man (not just in MacPorts; that's how "man" works on all  
platforms). So in order for "man dbmmanage" to be able to show you  
the dbmmanage manpage, the file dbmmanage.1.gz needs to be in the  
directory ${prefix}/share/man/man1. So for these ports to not  
conflict we would need to for example have the apache (1) port  
install files like dbmmanage1.1.gz instead. Then the user would have  
to type "man dbmmanage1" to read the manpage.


> Could I, as a port writer, use a system call to simply rm the man  
> page?

Yes, that capability exists. You can do anything you want in the post- 
destroot phase.

> These portfiles would have to be approved sparingly, and  
> cautiously, but in the end, heck it is just a man page.

manpages are a common way for people to learn about software, so I  
would be hesitant to remove them in any port.

There may also be other conflicting files besides manpages. I haven't  
checked. MacPorts only prints the name of the first conflicting file  
and then aborts.


>>> 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.

The variant was never updated for Leopard. It only works with Apple's  
Apache 1, thus it only works on Mac OS X 10.4 and earlier. There  
really haven't been that many complaints about this, certainly not  
recently. So perhaps we could reconsider whether we need to offer  
support for Apple's Apache at all anymore, since by necessity all  
Leopard users who are using php5 with Apache are already using the  
MacPorts apache2 port to do so.

> 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.

Mac OS X Server's apache is probably different from Mac OS X's apache  
in several ways and the variant of php5 was designed for Mac OS X's  
apache, not Mac OS X Server's.

>> 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.

The port is free to output an additional message in this case. I  
don't think we have that many kernel extension ports in MacPorts that  
it merits adding a special message to MacPorts base for this  
circumstance.

>> 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.

Anyone should be able to edit the wiki.