1 |
Hi Paul, |
2 |
|
3 |
Thanks for joining in. I was getting worried that this was turning into the |
4 |
'Max & Stuart Show' ;-) |
5 |
|
6 |
Here's my rambling thoughts about how the 'local' USE flag (can we call it |
7 |
'-vhosts' instead? 'local' feels a bit non-descript to me) could work, and |
8 |
what problems might occur. I'm sure that my thoughts here aren't the only |
9 |
possible solution. |
10 |
|
11 |
Under the '+vhosts' approach, webapps would be SLOT'd, and would go into |
12 |
|
13 |
/usr/share/webapps/${PF}/ |
14 |
|
15 |
and users would have to use the -config toolset to then make the app available |
16 |
inside one or more vhosts. |
17 |
|
18 |
What would happen in the '-vhosts' world? |
19 |
|
20 |
I think it all pivots around one crucial design decision. In the '-vhosts' |
21 |
world, do we want 'emerge -u' to be all that the user has to do (i.e. no need |
22 |
for the -config toolset)? If not, then I can't see what '-vhosts' would |
23 |
actually do, and I'd suggest dropping it. |
24 |
|
25 |
Let's explore what changes the 'emerge -u' objective might have to bring into |
26 |
the design. |
27 |
|
28 |
I think that SLOT'ing webapps would have to be switched off when '-vhosts' is |
29 |
in effect. Can we dynamically change the SLOT value inside an ebuild without |
30 |
upsetting Portage? Let's assume we can for the moment. |
31 |
|
32 |
I think the webapp would have to be installed directly under the |
33 |
'DocumentRoot' (/home/httpd/htdocs currently for Apache), instead of |
34 |
/usr/share/webapps/. Would this create support hell if a user then wanted to |
35 |
move to vhosting on the same box? emerge -C <webapp> will clean up |
36 |
correctly, so I'm not worried about that. I think we could live with this. |
37 |
|
38 |
As for config-protecting a webapp's configuration files, I'd do it by making |
39 |
the eclass add the config files to the CONFIG_PROTECT mask somehow. The |
40 |
webapp ebuild needs to be able to identify the package's config files as part |
41 |
of the '+vhosts' solution, so the information would be available. But I |
42 |
wonder if we'd need a change to Portage to allow the eclass to dynamically |
43 |
add these files to the CONFIG_PROTECT mask. It wouldn't need to be a |
44 |
permanent addition - in fact, I'd argue against it. |
45 |
|
46 |
(Lots of laughter. Just listening to the radio, and apparently the heatwave |
47 |
we're having right now is causing parts of one of our busiest motorways to |
48 |
melt). |
49 |
|
50 |
Speaking of eclasses, one way to hide the differences of the +/-vhosts world |
51 |
from the ebuild is to handle the differences entirely in the eclasses. |
52 |
|
53 |
# webapp.ebuild |
54 |
inhert webapp-proxy |
55 |
|
56 |
# webapp-proxy.eclass |
57 |
use 'vhosts' && inherit webapp-vhosts || inherit webapp-simple |
58 |
|
59 |
webapp-vhosts.eclass (or whatever it's called) would have to present the same |
60 |
interface (same functions w/ same parameters in) as webapp-simple.eclass. |
61 |
|
62 |
Just some thoughts, |
63 |
Stu |
64 |
-- |
65 |
On Tuesday 05 August 2003 10:34 am, Paul de Vrieze wrote: |
66 |
> Ok what about the following. |
67 |
> |
68 |
> The problem that is most existent in this case is the fact that you want |
69 |
> the eclass to support almost every kind of use. That is nice indeed. But |
70 |
> making things easy for single hostname smalltime servers, and for extensive |
71 |
> virtual hosting supports with customized webservers etc. is complicated. |
72 |
> Also in that case default apache configuration snippets don't make that |
73 |
> much sense. I think a solution could be to introduce a "local" useflag that |
74 |
> selects behaviour. |
75 |
> |
76 |
> If you have a simple webserver for personal use, you can just leave things |
77 |
> as they are and you can just run the config script or take some simple |
78 |
> actions and everything works. For the other case the configuration tool can |
79 |
> be used to create instances of a webapp for different virtual servers. That |
80 |
> tool would probably need some configuration file etc. and it might even |
81 |
> perform changes to the CONTENTS file to make the instances being included |
82 |
> in the ebuild (when removing). It could then also automatically change the |
83 |
> slot of the installed package so that it does not automatically get |
84 |
> removed. |
85 |
> |
86 |
> I think that should be able to keep both sides happy. |
87 |
> |
88 |
> Paul |
89 |
> |
90 |
> ps. one thing I want to add though is that for a simple installation I |
91 |
> think the configuration files should be config-protected (how that is |
92 |
> aranged I don't care), and for complex setups the instance configurations |
93 |
> should also be protected in some way (but that might be handled by the |
94 |
> tool) |
95 |
|
96 |
-- |
97 |
Stuart Herbert stuart@g.o |
98 |
Gentoo Developer http://www.gentoo.org/ |
99 |
Beta packages for download http://dev.gentoo.org/~stuart/packages/ |
100 |
|
101 |
GnuGP key id# F9AFC57C available from http://pgp.mit.edu |
102 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
103 |
-- |