1 |
> ... |
2 |
> Due to a lack of standard install method configuration files are at |
3 |
> risk of being overwritten during upgrade, potentially causing system |
4 |
> administrators down tine as they have to reconfigure web applications |
5 |
> after an upgrade. |
6 |
|
7 |
(typo) down time. Also how about say "after each upgrade." |
8 |
|
9 |
> 2. Application Location |
10 |
> ----------------------- |
11 |
> ... |
12 |
> A suggested alternative installation location for web applications, |
13 |
> outside of the Document: |
14 |
|
15 |
outside Document Root? |
16 |
|
17 |
> * for files to be served to clients:: |
18 |
> |
19 |
> /usr/share/webapps/<application>/files/ |
20 |
|
21 |
I think this should just be /usr/share/webapps/<application>/ |
22 |
|
23 |
> * for documentation files (not served to clients):: |
24 |
> |
25 |
> /usr/share/doc/webapps/<application>/ |
26 |
|
27 |
Perhaps keep things consistant and put docs in /usr/share/doc/${PF}. This |
28 |
way the current dodoc() and dohtml() utility functions can continue to be |
29 |
used without extra effort on behalf of the ebuild writers. |
30 |
|
31 |
> 3. Application Configuration |
32 |
> ---------------------------- |
33 |
> ... |
34 |
> * Apache configuration directives: |
35 |
> |
36 |
> - install a sample file in:: |
37 |
> |
38 |
> /usr/share/doc/webapps/<application>/conf/ |
39 |
> |
40 |
> the ebuild should inform the user how to include this |
41 |
> information in their Apache configuration. |
42 |
> |
43 |
> - alternatively the configuration directives could be placed in:: |
44 |
> |
45 |
> /etc/apache{1,2}/conf/webapps/<application> |
46 |
> |
47 |
> this directory and the files in it should be included by the |
48 |
> main Apache configuration file. |
49 |
> |
50 |
> By installing application configuration files in /etc Portage |
51 |
> CONFIG_PROTECT features can be used to ensure that configuration files |
52 |
are |
53 |
> not overwritten. |
54 |
|
55 |
The eclass currently puts them as /etc/webapps/<application>.conf. This |
56 |
way they are parallel to the application configuration files and are also |
57 |
web-server independent, all while being protected by CONFIG_PROTECT. The |
58 |
ebuild informs the user to how to activate the installed app which, when |
59 |
executed, |
60 |
just creates a link into the already-configured apache directory. |
61 |
|
62 |
|
63 |
Some other difficulty I came across while installing various webapps that |
64 |
we may want to address (perhaps not in this GLEP, but definitely sometime |
65 |
down the road) are: |
66 |
|
67 |
- Determining what modules mod_php has built into it. Currently, I have |
68 |
a quick and dirty function in the webapp eclass called check_php() which |
69 |
looks for a particular USE flag in /var/db/pkg/dev-php/mod_php*/USE. |
70 |
This probably needs to be a bit cleaner. |
71 |
- Certain web applications need to have write access to the directory where |
72 |
they are installed (curse them!) :-) |
73 |
- Great care must be taken to properly prepare the configuration files. |
74 |
For example, Horde config files have paths defined relative to the config |
75 |
file itself so some sed magic was used to fix a lot of it. |
76 |
|
77 |
Otherwise I am thrilled to see all this progress. Thank you! |
78 |
Standardization should always be applauded. :-) |
79 |
|
80 |
--mk |
81 |
|
82 |
-- |
83 |
gentoo-dev@g.o mailing list |