Webserver ports

[Rainer Müller]

Ryan Schmidt wrote:
> I think our web server ports are a bit of a mess. We have apache,  
> apache2, apache20 and lighttpd, that I know of. They each have their  
> default htdocs and cgi-bin directories in different places:
> 
> apache: ${prefix}/var/www/data/data (weird), ${prefix}/var/www/cgi-bin
> apache +apache_layout: ${prefix}/apache/htdocs, ${prefix}/apache/cgi-bin
> apache2: ${prefix}/apache2/htdocs, ${prefix}/apache2/cgi-bin
> apache20: ${prefix}/apache20/htdocs, ${prefix}/apache20/cgi-bin
> lighttpd: /srv/www/htdocs (very weird), no cgi-bin directory defined

/srv is part of the Filesystem Hierarchy Standard. Some Linux
distributions switched from /var/www to /srv/www.

> [...]
> We have several ports that install into either subdirectories of or  
> directly into ${prefix}/www, such as bugzilla, viewcvs, awstats,  
> gallery, htdig, mediawiki, phpbb, phpmyadmin, squirrelmail and  
> wordpress.
> 
> I propose:
> 
> * All web server ports should come with config files set to serve  
> files from the document root ${prefix}/www/htdocs and CGIs from $ 
> {prefix}/www/cgi-bin

I would prefer ${prefix}/var/www being used. The path ${prefix}/www is
just another violation of our mtree layout. Looking in porthier(7), it
already contains ${prefix}/var/www and denotes it for files being served
by a webserver.

For compatibility to existing ports, we could add a small port (like
compat-www-symlink) which just contains a symlink from ${prefix}/www to
${prefix}/var/www.

The existing ports installing to ${prefix}/www would be changed to
${prefix}/var/www and declare dependency on compat-www-symlink. This
way, existing configurations should not break. After some time
compat-www-symlink can be removed after announcement on macports-users.

> * There should be a meta port called "webserver" which has variants  
> for each of the four web servers mentioned above, defaulting to the  
> most popular, apache2
> * There should be a portgroup called "webapp" which sets up common  
> webapp tasks, like having no configure or build phases, depending on  
> port:webserver, and offering a variant "apple_webserver" to change  
> the install location from a MacPorts web server to the Apple one  
> (what do you think about this variant idea?)
> * All web app ports can be changed to use the "webapp" portgroup and  
> can remove any variants they have for fiddling with install location  
> or web server dependencies

Nice idea, I like this approach.

> Also:
> 
> * The "webserver" port can install a pretty MacPorts default  
> index.html page, like the default "It works!" page Apache provides,  
> but tailored to MacPorts

That would only be a bonus ;-)

Sorry for the late reply to this thread, the recent discussion on
macports-users about the apache2 layout brought it back to my attention.

Rainer