From owner-freebsd-ports@FreeBSD.ORG Thu May 11 11:33:46 2006 Return-Path: X-Original-To: ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E4B5216A504; Thu, 11 May 2006 11:33:46 +0000 (UTC) (envelope-from o_sleep@belovedarctos.com) Received: from mail.belovedarctos.com (mail.belovedarctos.com [66.114.86.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A72F43D73; Thu, 11 May 2006 11:33:46 +0000 (GMT) (envelope-from o_sleep@belovedarctos.com) Received: from [10.0.1.99] (unknown [10.0.1.99]) by mail.belovedarctos.com (Postfix) with ESMTP id E49DB8734; Thu, 11 May 2006 11:33:43 +0000 (UTC) In-Reply-To: <20060511110811.GF79700@goofy.cultdeadsheep.org> References: <1147338576.799.9.camel@pav.hide.vol.cz> <44630121.6030303@FreeBSD.org> <20060511110811.GF79700@goofy.cultdeadsheep.org> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bjorn Nelson Date: Thu, 11 May 2006 07:33:41 -0400 To: Clement Laforet X-Mailer: Apple Mail (2.749.3) Cc: ports@FreeBSD.org, pav@FreeBSD.org, Doug Barton Subject: Re: HEADS UP for maintainers of web applications X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2006 11:33:47 -0000 Doug, Is this laid out somewhere in a doc? I have a bunch of questions regarding this that would probably be addressed if I saw the new guideline. Some of my questions are: Does this mean web apps will need to be put under the apache versioned doc? Is apache conf still located under /usr/local/etc/apacheversion? Are symlinks really that bad? We could have the apache versions be symlinks to the document root and possibly have the option of multiple versions of apache installed. Also, my understanding of the current system was documentroot: /usr/local/www/data webapps go here: /usr/local/www (separated from document root so sensitive app files aren't automatically/accidently exposed) files that may be shared by multiple apps or multiple instances of an app go here: /usr/local/share -Bjorn Nelson On May 11, 2006, at 7:08 AM, Clement Laforet wrote: > On Thu, May 11, 2006 at 02:17:21AM -0700, Doug Barton wrote: >> Pav Lucistnik wrote: >>> Hi people, >>> >>> it will soon become mandatory to stop installing web applications >>> into >>> Apache specific directories, like ${PREFIX}/www/data, >>> ${PREFIX}/www/cgi-bin etc. >> >> How did those directories become "apache specific," and where was >> that >> decision and the prohibitive policy discussed and agreed to? > > As Pav said previously, they are installed by apache. We have reasons > to get rid of this: > - Apache is not the unique web server. lighttpd seduces many people > - Web application are bigger and more complex. > - Where are installed your web apps/front end? > ${PREFIX}/share/${PORTNAME} like nagios or cacti? > So you have to hack apache 2* conf. It's far from being > intuitive. > ${PREFIX}/www/data/${PORTNAME}? > data is not in MTREE... > ${PREFIX}/www/${PORTNAME}? > > I'm also thinking about making apache ports I maintain more flexible > is the post-install stage, I'd like to see more automated tasks, > specially for installations of modules, support of mac_bsdextended(4), > out-of-the-box apache configuration for webapps and such. > With a "strict" hierarchy, we can do it. > > OTOH, www/apache22 doesn't support old layout, and many users > complained, because they were stuck with apache2* ports ACL (it's > locked to DocumentRoot which is ${PREFIX}/www/apache22/). This > situation sucks and I'm the one to blame. But I don't think I'll go > back to ${PREFIX}/www/{data,cgi-bin,icons} and its symlinks mess. > I'll surely add a misc/webhier or so to fix this issues, and it will > surely help non-apache webservers ports to provide a coherent web > hierarchy... ... and fix the ugly cgi-bin issue too (cvsweb problems) > > > clem