Summary: | problems webapps-apache installing to non-HTTPD-ROOT path | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Chris Verges <squirrel> |
Component: | [OLD] Server | Assignee: | Gentoo Web Application Packages Maintainers <web-apps> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | php-bugs, twp |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Chris Verges
2003-11-05 22:55:25 UTC
webapp-apache is obsolete, however phpmyadmin should have only installed to /var/www/localhost/htdocs at this time (this is a hard decision that we have made until the vhost-config and webapp-config have been completed). Eg it should not take any input to control this yet. According to the grep comment in webapp-apache: HTTPD_ROOT="`grep '^DocumentRoot' ${APACHECONF} | cut -d ' ' -f 2`" It looks to me as though it will install to whatever the DocumentRoot is set to in /etc/apache2/conf/apache2.conf. If this DocumentRoot is different than the default, why should it have still installed to the default path? Because supporting DocumentRoot is never going to be clean unless there is proper support for this in Portage. If you build a .tbz2 package of an ebuild on a machine with the default DocumentRoot, then install that .tbz2 on a machine with a different one, you're out of luck. Same thing if the situation is reversed. Therefore, there can be only one. I think my point is more that I don't understand why there isn't a way to override the default install root when desired. Couldn't the ebuild have been built to detect if HTTPD_ROOT is set prior to calling webapp-pkg_setup? If HTTPD_ROOT is not set, then the ebuild needs to call webapp-pkg_setup to properly configure everything. (Or perhaps inside webapp-pkg_setup perform this checking.) Chris, you seemed to ignore what I said: 'webapp-apache is obsolete' ultimately with vhost-config and webapp-config, the behavior is this: case 1 (not using vhosts): all web applications are installed to /var/www/localhost/htdocs or a fixed location (vhost-config/webapp-config _may_ [but probably not at this point] have this in a configuration file, but we will definetly be going away from parsing the apache config, just because it's so error-prone). if you are using non-standard locations, expect big flashing warnings about moving the tbz2 between machines. case 2 (using vhosts): on emerge, the package is installed to a location is that seperate, possibly /usr/share/webapps/${PF}/ or something of the sort. you can create/edit/delete vhosts using vhost-config (modeled after zope-config to a degree). then using webapp-config (modeled after zprod-manager to a degree) you will be able to add/remove webapps to each of the defined vhosts. Sorry, I didn't ignore what you said. I was merely pointing out that claiming a component of an ebuild is obsolete does not fix the problem that the ebuild does not have the desired functionality. As the original author, I'm sorry that webapp-apache (in this case) won't do what you want it to do. It wasn't designed to support virtual hosts. We have a new approach for dealing with that, which we hope to introduce as soon as possible. Robin's right - it is obsolete, and I won't be making changes to it in future. Sorry. Best regards, Stu |