1 |
Hi everyone, |
2 |
|
3 |
Sorry that this is a bit lengthy, but there's a fair bit to cover for those |
4 |
who are interested in this ... |
5 |
|
6 |
I've just committed the first (and untested!) webapp.eclass into Portage, so |
7 |
that all interested parties can see my initial thoughts on how we could |
8 |
handle ebuilds. |
9 |
|
10 |
Please note: if you actually want to *run* webapp.eclass, you need to place |
11 |
the attached 'webapp-config.sh' file into /usr/share/webapp-config/ first. |
12 |
This file will be supplied by the webapp-config package when I'm ready to |
13 |
commit that to CVS. |
14 |
|
15 |
Please note: I'm making this available for REVIEW. It's certainly not here |
16 |
for us to start porting web-based applications to ;-) We need something to |
17 |
kick off implementing GLEP #11, so here you go. I'm sure that the final |
18 |
version will look quite different, and the best way to do that is to get as |
19 |
many people as possible looking at it. |
20 |
|
21 |
How it's supposed to work: The key idea here is that ebuilds will no longer |
22 |
install web-based applications directly into anywhere. As discussed in GLEP |
23 |
#11, we're moving to a two-stage install process. The job of the ebuild is |
24 |
now to install web-based applications into /usr/share/webapps/, so that a |
25 |
tool called webapp-config can then install the web-based application into the |
26 |
htdocs directory of your choice later. |
27 |
|
28 |
As part of this, the ebuild needs to provide extra information about the files |
29 |
to be installed. The extra information includes: |
30 |
|
31 |
1) which files need to be owned by the webserver's user:group combo (for |
32 |
write-access purposes). All other files will be owned by another user (to be |
33 |
determined; perhaps root, but perhaps not) |
34 |
2) script files executed by the webserver. Normally, the relevant |
35 |
mod_php/mod_perl/mod_ruby would handle these, but we need to know what they |
36 |
are in case we provide PHP/CGI and so on in the future. |
37 |
3) config files - files that need to be unique when second part of the |
38 |
two-stage install process kicks off. Files not on this list will be made |
39 |
available to the webserver via smoke and mirrors instead ;-) |
40 |
|
41 |
I'm sure that we'll need to add to this list when we start converting ebuilds |
42 |
en-masse across to the final solution. |
43 |
|
44 |
I've attached a (in-progress!) ebuild for tikiwiki-1.7.1.1, to show how I see |
45 |
it working. |
46 |
|
47 |
NOTE: I said this is a two-stage process. If 'vhosts' is NOT in the USE |
48 |
flags, the eclass automagically kicks off the second stage of the process, so |
49 |
that (when the time comes) existing install behaviour remains. |
50 |
|
51 |
At the moment, I'm working on a first-cut of the webapp-config tool. It'll be |
52 |
a bash script at first. Once the behaviour, and the interface in is stable, |
53 |
I'm thinking of recoding it in something else, so that it can be installed |
54 |
setuid root. |
55 |
|
56 |
Max - I'd really appreciate your comments in particular. You've put a lot of |
57 |
work into the Horde stuff, and I'm sure I haven't covered it all yet ;-) |
58 |
|
59 |
I've opened bug #30607 for tracking all the feedback about this work. Please |
60 |
post there, rather than reply to this. |
61 |
|
62 |
Thanks, |
63 |
Stu |
64 |
-- |
65 |
Stuart Herbert stuart@g.o |
66 |
Gentoo Developer http://www.gentoo.org/ |
67 |
Beta packages for download http://dev.gentoo.org/~stuart/packages/ |
68 |
Come and meet me in March 2004 http://www.phparch.com/cruise/ |
69 |
|
70 |
GnuGP key id# F9AFC57C available from http://pgp.mit.edu |
71 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
72 |
-- |