apache2 location

[Scott Haneda]

On Feb 26, 2009, at 1:16 AM, Ryan Schmidt wrote:
> This is a mega-reply to many previous messages in this thread.

Mega indeed, thanks for this.

> On Feb 24, 2009, at 16:35, Scott Haneda wrote:
>> If I modify the port to put apache in www, I believe that to be the  
>> correct place based on the above url, is this a huge undertaking  
>> that is going to require a lot of discussion to not break thing?   
>> Every path is going to need to change.
>
> Apache does not belong in ${prefix}/www. That directory is for web  
> site data (htdocs, cgi-bin, etc.)

That was an error on my part, just wrong line of thought, I sort of  
correct myself later on, but yeah, www would be wrong.

>> To me it is worth it to follow the guidelines of MacPorts, but this  
>> may be one that is so engrained in MacPorts, it might not want to  
>> change.
>
> I'm not opposed to changing apache2 (and apache and apache20) to  
> conform better to the MacPorts directory layout. apache2 is  
> maintained by James Cox who hasn't been very active with MacPorts  
> recently so we will have to take some initiative to decide what  
> exactly we want to change, file a ticket, attach a new portfile  
> proposal, and if James doesn't reply in awhile, we can commit it.  
> apache20 is maintained by Blair Zajac and is supposed to be similar  
> to apache2 in all respects except the version, so we should be able  
> to make the same changes there. apache is maintained by me with  
> openmaintainer. It currently has two different modes of installation  
> (two different possible layouts); this should be changed to just a  
> single layout that agrees with whatever we choose for the apache2  
> layout.

Ok, let me think of the layout, and hash out it here, and in my head,  
and I will open a ticket.

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

>> My feeling is, the sooner the better, there are already a handful  
>> of blogs out there, which instructions and hard paths in their  
>> instructions pointing to the current location.  The sooner we put  
>> it where MacPorts recommends, the better the long term usability is  
>> going to be.
>
> We have our own documentation in the MAMP wiki page which should be  
> canonical and up to date with the current state of the ports,  
> whatever that may be. Users should always look there first.

Should and do are different :) When it comes to MAMP, I would say,  
more often than not, they google MAMP, ending up at macports is pretty  
far down on the list.  Before they hit macports, they are going to hit  
a blog, and download and follow some instructions there.  This is not  
really a MacPorts issue, since you feel MacPorts should be the  
definitive place to go, if the other blog instructions become wrong,  
they can update, or link back as they should have in the first place.

> On Feb 24, 2009, at 19:03, Scott Haneda wrote:

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

> On Feb 24, 2009, at 22:25, Scott Haneda wrote:
>
>> I have a feeling I am going to stand alone on this one, which is  
>> fine, I have no intention of pushing it, this was just to find out  
>> why this was chosen,
>
> You don't stand alone on this issue, I don't think there's a need to  
> argue the benefits of putting the software into the standard  
> directories, we just need to consider what the exact directory  
> layout should be and then change the port to put the files there.

I will start the process with a trac port, and a directory suggestion.

>> and why it was not caught as in violation of suggested layouts.  
>> There is even a patch where the violate_mtree option was added in  
>> trac.  Not that long ago either, where did apache 2 install prior  
>> to that?
>
> As far as I know, the apache2 port has always installed to ${prefix}/ 
> apache2. The mtree checking code was added relatively recently to  
> MacPorts base. Prior to that, no checking was done. Ports could  
> install files wherever on the user's system and the user would never  
> know unless they looked at "port contents". Now that checking is  
> done, a warning is printed at install time if a port installs to a  
> nonstandard location. It reads like this:
>
> Warning: violation by /opt/local/apache2
> Warning: apache2 violates the layout of the ports-filesystems!
> Warning: Please fix or indicate this misbehavior (if it is  
> intended), it will be an error in future releases!
>
> As a result, "destroot.violate_mtree" was added to the port to  
> indicate that this violation of the standard directory structure was  
> intentional (i.e. was not an accident). Now the warning reads as you  
> originally noted:
>
> Warning: apache2 requests to install files outside the common  
> directory structure!

Thanks for the clarification, makes sense how it all happened now.  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.

Actually, are there any valid reasons ever, at all, to violate-mtree,  
or is this just legacy support?

> On Feb 24, 2009, at 22:41, Scott Haneda wrote:

> Ports should not install things that Apple Software Update may  
> overwrite. The whole point of having a separate MacPorts prefix is  
> to isolate MacPorts-installed software from Apple-installed software.

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.

>> What I can say, is I am more than a new ports user, still beginner,  
>> but if I were a totally new user, this would be a hang-up to me,  
>> maybe most just let it go and ignore the warning, I tend to not be  
>> that person, as these emails probably illustrate :)
>
> Could you suggest an alternate wording of the message that would  
> make it more clear to you that the port is deliberately installing  
> files into nonstandard places and that you as a user should simply  
> be aware of that fact?

A lot of that is going to depend on your answers to why it is even  
allowed.  If the functionality to actually put files outside of prefix  
is in MacPorts, then I want the sternest of warnings to be printed  
out.  If that is simply not allowed, then we need not worry about any  
warning, as it can not happen.

That leaves installs going into non standard places. Unless someone  
can show me a few examples of pretty compelling reasons why this is a  
good idea, it may make sense to just ban the ability.

I do not have new verbiage, because...

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

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.

> On Feb 25, 2009, at 08:11, Chris Janton wrote:
>> The configuration files could be put in /opt/local/etc/httpd
>
> That sounds reasonable. But both apache (1) and apache2 are called  
> "httpd" so we may want to use ${prefix}/etc/apache2 and ${prefix}/ 
> etc/apache instead so that a user who has tried more than one of  
> apache and apache2 will not be confused. An apache (1) configuration  
> file would not be appropriate for use with apache2 and vice versa.  
> The same goes for whatever directory we choose for apache modules --  
> these are not compatible between versions.

I like this, and it mimics /etc/apache2 on OS X now.  I believe  
Apache1 was /etc/httpd but those days are long gone.  Your suggestion  
of this layout is good and what I was thinking as well.  it is a small  
bummer for tab completion if you have a side by side install of both,  
but that is not the normal case.

> On Feb 25, 2009, at 16:05, Adam Byrtek wrote:
>
>> Scott, I think that in principle you are right. On the other hand I
>> can understand that many people are used to the current layout and if
>> the change is accepted, some reasonable migration strategy will have
>> to be prepared. Such migration shouldn't involve any manual work
>> and/or data loss.
>
> If we rearrange the layout of apache2, you should not necessarily  
> expect it to handle any migration of config files or data for you.  
> You should expect to have to do so manually. It would not be proper  
> for MacPorts to move files that are not registered to a port.

There may be resistance to this, but only once, fix it now, and I  
think we will be better in the long run. Dealing with the cofig files  
cold be handled with an external shell script I would be happy to look  
into doing.

> The new port could check whether, say, the httpd.conf exists at the  
> location where the old port looked for it, and in that case, print a  
> message explaining the new layout to the user and recommend they  
> move their files.

Sounds reasonable.

> Any apache2 modules (for example php5) would have to be rebuilt by  
> the user so that they get installed into the new module directory.  
> The apache2 port cannot do this for you. It might be possible for  
> apache2 to figure out which modules you have installed and tell you  
> which ports you have to rebuild, though that would take a little work.

I think you will find, most users have the same module kit installed  
by following the MAMP guide.  Those who did more, I would assume they  
knew what they wanted, and this is a small issue to them.

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

> On Feb 26, 2009, at 01:35, Bill Hernandez wrote:
>
>> I just like going to /opt/local/apache2 and finding everything  
>> related to apache in one spot.
>>
>> I remember when I did one of my first installs and began trying to  
>> track down the logfiles to mysql and pgsql. It took me some time to  
>> locate them due to what I considered to be some inconsistencies.  
>> Now that I have done this a few times, it doesn't matter where the  
>> stuff lives. It is obvious that I was only considering the  
>> convenience, and not the practicality.

And remember, you can gain a ton of convenience by just making bash  
aliases, symblinks etc to drop you right where you want to be.
--
Scott

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