| 1 |
Howdy Stuart! |
| 2 |
|
| 3 |
Quoting Stuart Herbert <stuart@g.o>: |
| 4 |
|
| 5 |
>> You want to mix the apache config block with other configuration files |
| 6 |
>> that come with the application? |
| 7 |
> |
| 8 |
> /etc/webapps/<application>/ is the directory for the *application's* |
| 9 |
> config files. Nothing to do with Apache per se. |
| 10 |
|
| 11 |
Correct. I also create an apache config block as |
| 12 |
|
| 13 |
/etc/webapps/<application>.conf |
| 14 |
|
| 15 |
This is what gets included into the apache config if a user activates the |
| 16 |
specific application. For example, the horde config block looks like this: |
| 17 |
|
| 18 |
max@ike webapps $ cat horde-apache.conf |
| 19 |
Alias /horde /usr/share/webapps/horde/ |
| 20 |
<Directory /usr/share/webapps/horde> |
| 21 |
Allow from all |
| 22 |
AllowOverride Limit |
| 23 |
Options Indexes FollowSymLinks |
| 24 |
php_flag safe_mode off |
| 25 |
php_flag magic_quotes_gpc off |
| 26 |
php_flag magic_quotes_runtime off |
| 27 |
php_flag register_globals off |
| 28 |
php_flag file_uploads on |
| 29 |
php_value upload_max_filesize 50M |
| 30 |
php_value include_path /usr/lib/horde-pear |
| 31 |
</Directory> |
| 32 |
|
| 33 |
> There is an alternative that should be considered. Maybe there shouldn't |
| 34 |
> be an /etc/webapps directory at all, and the config files should live |
| 35 |
> under the Document Root. Yes, this might be better. How would you |
| 36 |
> support multiple installations of phpMyAdmin using a /etc/webapps/ |
| 37 |
> scheme? |
| 38 |
|
| 39 |
The whole reason for keeping config files under /etc is for CONFIG_PROTECT. |
| 40 |
Multiple versions of any app would be handled the same way as all other |
| 41 |
packages on Gentoo -- core files get overwritten in an upgrade and the |
| 42 |
config files are updated through dispatch-conf/etc-update/manually. |
| 43 |
|
| 44 |
>> Yes! Which is why a patch is probably not always appropriate -- sed is |
| 45 |
>> more resilient to pieces of configuration moving around upstream. |
| 46 |
> |
| 47 |
> Not sure I understand you here. A patch is applied against a known set |
| 48 |
> of files. Portage only installs known sets of files. So a patch is no |
| 49 |
> less appropriate than sed. |
| 50 |
|
| 51 |
Right, but if the file itself gets rearranged constantly (as some apps do), |
| 52 |
it may be difficult to maintain the patch. But again, this all depends on |
| 53 |
the package at hand -- as stands right now everywhere else in gentoo, lets |
| 54 |
do what is easier/more maintainable. |
| 55 |
|
| 56 |
> Last night, I thought I was sure. Unfortunately, waking up today I've |
| 57 |
> forgotten ;-) I'll go back and re-read the thread. |
| 58 |
|
| 59 |
Don't you just hate when that happens :-) |
| 60 |
|
| 61 |
> We're going to use the one eclass for CGIs, mod_perl-dependent, |
| 62 |
> mod_python-dependent, and so on? Mmmm. That way lies pain and misery me |
| 63 |
> thinks. |
| 64 |
|
| 65 |
Currently there's nothing in the eclass that is language specific other |
| 66 |
than that check_php function (which, as I said before, I'd like to find a |
| 67 |
replacement for). |
| 68 |
|
| 69 |
> I think we'll need a webapps-base eclass, and then a webapps-<language> |
| 70 |
> set of eclasses. All the language-neutral stuff goes in the base, and |
| 71 |
> everything else goes into each specific language eclass. |
| 72 |
|
| 73 |
Certainly. Perhaps if we don't find anything that is language specific |
| 74 |
(which I have yet to see), we can take a different approach and do |
| 75 |
webapp-<webservertype> |
| 76 |
|
| 77 |
> Just what webserver-specific configuration do these apps need? I'd hope |
| 78 |
> that, for the vast majority of apps, it's little to none. |
| 79 |
|
| 80 |
See above. |
| 81 |
|
| 82 |
> It can't be that difficult - it's only a web server. |
| 83 |
|
| 84 |
Isn't that on the list of "Famous Last Words" ? :-) |
| 85 |
|
| 86 |
--mk |
| 87 |
|
| 88 |
-- |
| 89 |
gentoo-dev@g.o mailing list |
Archives