apache2 location

[Ryan Schmidt]

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


>>> Now I know what the error is about.  There are a lot of people I  
>>> try to get to use ports, and they all tell me they tried in the  
>>> past but could not get past errors, maybe this is one of those  
>>> issues.
>>
>> If users are encountering issues with ports, they should subscribe  
>> to macports-users and tell us about them so that we can fix them.  
>> Or they should file tickets in Trac.
>
> I do not want to detract too much on this, but a lot of users are  
> not going to do this.  If MacPorts is to gain more wide spread use,  
> you have to assume most of the users will not hit a mail list, will  
> not hit forums, and will just try it. If there is trouble in their  
> process, they may make a small effort to google it, and then  
> abandon.  Yes, they should come here, I agree. I also think that  
> the goal should be, software that does not need support, as  
> idealistic as that is in the other direction :)
>
> Since there are those users, some of whom I work with, I am  
> speaking on behalf of a few, since they are self proclaimed "busy"  
> people, and just are not going to make it here.

Sure. I'm just saying if problems are not reported to us we cannot  
fix them.


> I would like to see that any ports in the future, if the portfile  
> is submitted, and there is a "destroot.violate_mtree", some  
> discussion should be raised.

Sounds good to me.


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

php5 and all the other apache2 module ports of course also violate  
the mtree because they need to install into the MacPorts apache2  
modules directory which is in a nonstandard location, being inside $ 
{prefix}/apache2. So changing apache2 to not violate the mtree will  
fix these module ports as well.

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

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

All of the cross-compilers violate the mtree; hopefully there's a  
good reason for that as well.


> This comes back to my above comment then, why does  
> "destroot.violate_mtree" even exist?  MacPorts expressly forbids  
> outside of /opt, strongly discourages installs right into prefix,  
> just make it a steadfast rule.

Note the default prefix is /opt/local, not /opt, and MacPorts does  
not expressly forbid installing outside of it. Some locations outside  
of ${prefix} are fine, such as ${applications_dir} and /Library/ 
LaunchDaemons. MacPorts itself even installs outside of ${prefix} by  
default, into /Library/Tcl.


>> A suggestion I made some time ago was that each error or warning  
>> MacPorts can print should be rather short (no more than one line),  
>> and then it should print a URL to a wiki page where the error can  
>> be described in more detail. Each such error page should, I think,  
>> be divided into two sections: 1) what a user should do about this  
>> message, and 2) what a port author should do about this message.  
>> What do you think about this idea?
>
> This is an excellent idea.  We can sit here and try to debate the  
> perfect terse message, and never come to agreement.  MacPorts also  
> moves data across the screen pretty fast, if you are around 100  
> chars wide, it is wrapped, and a mess to read.  It really is not  
> the place for this info, for the detail we need to get across.

Well, you only get so much data moving across the screen so quickly  
if you enable verbose or debug mode, which most users won't need to do.


> 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


>> On Feb 25, 2009, at 16:51, Scott Haneda wrote:
>>
>>> Fully agree on that front.  It was why I wondered if this was too  
>>> engrained in how it was done, it just may not be worth it.  But,  
>>> then again, the move should be pretty simple, ports is sort of  
>>> designed by nature to fiddle with paths and move stuff around.
>>
>> It is not designed to move files that are not registered to a  
>> port. The apache config file httpd.conf and any web data you have  
>> installed are not registered to the apache2 port so it cannot move  
>> those files for you.
>
> I was not aware of that, thanks for clarifying.  I thought it did  
> to a degree, I seem to recall a apache port upgrade mucking up conf  
> files, from there I concluded they were registered.

apache2 stopped clobbering httpd.conf in r3875 (2003-10-31). It was  
fixed to additionally not clobber the extra config files in r43973  
(2008-12-18).