When tackling a cvsweb bug, I noticed the webapp-apache eclass needed a few extras for it to be more useable for ebuilds. My patch offers ebuilds the following extra variables: APACHECONF_COMMON APACHECONF_DIR HTTPD_CGIBIN it also makes HTTPD_ROOT detection use a trailing / when setting a default location. Reproducible: Always Steps to Reproduce:
Created attachment 15683 [details, diff] webapp-apache.patch
I'll leave this one to stuart since he seems to be the person in charge of that eclass
Sorry for the delay in looking at this. Here's my feedback on the patch. The stuff to work out where to put cgi-bin files I've no big problem with. I'll add that to webapp.eclass in the next day or so. Why do you need the trailing / on the HTTPD_ROOT definition? Best regards, Stu
Someone could called ${HTTPD_ROOT}somefile.txt (no /) - that'll break, having an extra / in there won't break anything, but it will stop breakage on situations where people forget one.
Mmm ... I'm not of fan of allowing people to get away with mistakes like that, but your point is well made. I've committed the patch, and it should be appearing on your local rsync mirror within the hour or so. Please take a look, and confirm that you're happy - then I can close this bug. Best regards, Stu
There are a few layout imperfections where the patch has been applyed, but apart from that I'm happy. Cheers.
Those 'imperfections' are where you use a different TAB size to the default for eclasses. Your patch converted the tabs to spaces, and when I edited the patch I didn't put the TABs back in. Best regards, Stu
Since the new v1.18 I get !!! ERROR: net-www/phpBB-2.0.5 failed. !!! Function webapp-pkg_setup, Line 80, Exitcode 0 !!! I couldn't find an installation of Apache It's definitely an eclass/Apache-1 problem, cause it's reproduceable with other ebuilds.
fyi: it's the webapp-determine-cgibindir() -z string True if the length of string is zero. (and the string usually isn't ;)
Doh! And double-doh, because our CVS server is currently borken, so I won't be able to commit v1.9 yet :( Best regards, Stu
Forigve me, I've just been to a beer festival... but I don't see how my patch is at fault. The -z is there because if the string is 0 then it sets a default, if it isn't 0 then we already found the cgi-bin dir. /me thinks its webapp-apache-detect at fault.
I'm jealous about the beer festival :) The pub I was in earlier this evening only had the one guest ale, and that wasn't available :( Nothing to forgive ... I didn't spot this first time around, and I have very extensive shell programming experience stretching out over ten years and over twenty different UNIX variants. What happens is this. When there is no explicit 'return' statement from a shell function, the return code of the last statement in the function is returned. webapp-detect-cgibindir() can return a zero (if the [ -z ... ] test is successful), or a one (if the [ -z ... ] test fails). webapp-detect-cgibindir() is the last statement inside webapp-detect(), so webapp-detect() returns whatever webapp-detect-cgibindir() returns. Unfortunately, this means that webapp-detect() can return a 1 even if webapp-apache-detect() successfully worked out which apache to use. The fix that'll go into CVS (when CVS is fixed :) is to make webapp-detect() explicitly return a 0 once webapp-detect-cgibindir() has been called. I hope that clears it up. Stu
This bug is now invalid due to the new webapp system.
