The reconfig script for www-apache/mod_survey contains these lines: if [ $1 = "install" ]; then sed -e "s|/usr/lib/mod_survey/webroot/|${MY_INSTALLDIR}/|g s|\"/mod_survey/\"|\"${VHOST_APPDIR}/\"| s|Alias|#Alias|" -i ${VHOST_ROOT}/${PN}/survey.conf || die This breaks mod_survey, since it relies on having a /mod_survey/ alias in all domains it works for. This is the location where stylesheets are located. The Alias statement is required for normal functionality. Suggest removing the the commenting out of the Alias statement, but am not sure if it breaks something else in re vhosts and webapps.
Well, my thinking was that this alias is unnecesary b/c the user can control where to install mod_survey via webapp-config. Does mod_survey always expect to find itself in /mod_survey?
Hrm.. In practise and in most cases you're right here. I just ran into the problem because I had used virtualmin to set up subdomains. Mod_survey registers the *.survey file type globally in apache, so surveys will be parsed for all subdomains even if they have not installed the /mod_survey directory. Layout will be borked in all domains that didn't install the files though. Since *.survey is registered globally I just felt intuitively that the alias /mod_survey/ should be too. All surveys in all subdomais requires that this exist, or at least that _SURVEY_ROOT_ALIAS (set in survey.conf) exist. To my thinking either the alias should exist in all domains, or the *.survey filetype shouldn't be registered globally. I guess the difference is if you see mod_survey as a file type interpreter like php or as an application like squirrelmail. Right now it's something in between. :-)
Makes sense. I'll defer to your judgment - what do you think we should do?
I can see three alternate ways. Approach one would be limiting the web app to the vhost that has it installed. This can be achieved with putting the *.survey type declaration in survey.conf inside a <Directory> block. If no vhosts use flag, register globally. I'm not literate enough with webapp-config to know if this is easy or not, but I imagine one would want to pre-fabricate a survey.conf and ship it rather than use the one produced by the install script. Approach number two is to move the contents of the mod_survey web root directory out of the web hierarchy (to /usr/share perhaps?) and register the /mod_survey/ alias globally again. Ie, remove the commenting out of the alias line in survey.conf. Approach number three is to largely ignore the problem. :-) As said, most people will never run into it. Those who do will have edited apache's config files manually already and will likely be able to solve the problem. Maybe a post-install note could be printed about it from the ebuild so that those few that run into the problem can perform the minor manual routine necessary to solve it. Way number two is most in line with how mod_survey works, but one and three I guess are more in line with how gentoo works. Right now I have a hangover and don't feel very judgemental. :-) I'll take a look at the consequences of the approaches in the weekend and suggest a patch or something.
ok, thanks. i'd rather not stick anything outside of /usr/share, as i prefer the gentoo way :)
any thoughts?
(In reply to comment #6) > any thoughts? > Only a sense of guilt that I didn't do anything about it. :-) It is soon time for a maintainance release of mod_survey anyway, as there are some minor things that should be updated. I've been thinking about writing a special section of the perl install script for gentoo. That way we could avoid having to sed the config file and move stuff around. Part of why I didn't do any thing about this before is because the sed:ing of the config file got so complicated when taking vhosts into account. I assume it is possible to pass an argument to the perl install script. That way it could manage vhosts in a sane manner if the use flag is specified, or register the app globally if -vhosts is true.
it's possible, but don't forget that the perl script is run at the ebuild stage, when nothing is known about which vhost the app is going to be installed into.
Hello, Please reopen this bug when you have more info for us.
