From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32273 invoked by uid 1002); 2 Aug 2003 23:11:32 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 842 invoked from network); 2 Aug 2003 23:11:31 -0000 Date: Sat, 02 Aug 2003 16:11:29 -0700 From: Max Kalika To: Troy Dack , gentoo-dev@gentoo.org Message-ID: <2147483647.1059840689@[192.168.26.4]> In-Reply-To: <1059843010.5023.80.camel@carbon.internal.lan> References: <1059843010.5023.80.camel@carbon.internal.lan> X-Mailer: Mulberry/3.1.0b4 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: [gentoo-dev] Re: [gentoo-core] [GLEP] Web Application Installation X-Archives-Salt: c3e4b201-4ebc-4712-95c8-d0f2ad3d8b52 X-Archives-Hash: 835fbcf8956e3984c98bac53a4ac2a74 > ... > Due to a lack of standard install method configuration files are at > risk of being overwritten during upgrade, potentially causing system > administrators down tine as they have to reconfigure web applications > after an upgrade. (typo) down time. Also how about say "after each upgrade." > 2. Application Location > ----------------------- > ... > A suggested alternative installation location for web applications, > outside of the Document: outside Document Root? > * for files to be served to clients:: > > /usr/share/webapps//files/ I think this should just be /usr/share/webapps// > * for documentation files (not served to clients):: > > /usr/share/doc/webapps// Perhaps keep things consistant and put docs in /usr/share/doc/${PF}. This way the current dodoc() and dohtml() utility functions can continue to be used without extra effort on behalf of the ebuild writers. > 3. Application Configuration > ---------------------------- > ... > * Apache configuration directives: > > - install a sample file in:: > > /usr/share/doc/webapps//conf/ > > the ebuild should inform the user how to include this > information in their Apache configuration. > > - alternatively the configuration directives could be placed in:: > > /etc/apache{1,2}/conf/webapps/ > > this directory and the files in it should be included by the > main Apache configuration file. > > By installing application configuration files in /etc Portage > CONFIG_PROTECT features can be used to ensure that configuration files are > not overwritten. The eclass currently puts them as /etc/webapps/.conf. This way they are parallel to the application configuration files and are also web-server independent, all while being protected by CONFIG_PROTECT. The ebuild informs the user to how to activate the installed app which, when executed, just creates a link into the already-configured apache directory. Some other difficulty I came across while installing various webapps that we may want to address (perhaps not in this GLEP, but definitely sometime down the road) are: - Determining what modules mod_php has built into it. Currently, I have a quick and dirty function in the webapp eclass called check_php() which looks for a particular USE flag in /var/db/pkg/dev-php/mod_php*/USE. This probably needs to be a bit cleaner. - Certain web applications need to have write access to the directory where they are installed (curse them!) :-) - Great care must be taken to properly prepare the configuration files. For example, Horde config files have paths defined relative to the config file itself so some sed magic was used to fix a lot of it. Otherwise I am thrilled to see all this progress. Thank you! Standardization should always be applauded. :-) --mk -- gentoo-dev@gentoo.org mailing list