1 |
Hi Max, |
2 |
|
3 |
Looks like we're almost there, doesn't it? ;-) |
4 |
|
5 |
On Tuesday 05 August 2003 4:04 am, Max Kalika wrote: |
6 |
> >> The most robust solution would be to create a new group (web?) and make |
7 |
> >> all the webserver users be a part of that group and make these directory |
8 |
> >> group-owned by said group. (Similar to the "mail" group for many |
9 |
> >> mail-related services) |
10 |
> > |
11 |
> > Why is that robust? |
12 |
> |
13 |
> Because we have the one group that we know all webservers are going to run |
14 |
> as (yes yes, the sysadmin can change what group the server runs as, and if |
15 |
> he/she does, then he/she can also change the ownership of the directory). |
16 |
> If we assume that all webservers will run as the same group, then |
17 |
> configuring those apps which need a writeable directory becomes easy |
18 |
> indeed. |
19 |
|
20 |
We'd need to get Donnie on board to make this happen. |
21 |
|
22 |
I'd just assumed that the webapp-config toolset would automagically take care |
23 |
of this for us (see my earlier post about what assumptions are ;-) |
24 |
|
25 |
> > (thinks about this) I'd want to test it to be sure, but I think ${PF} |
26 |
> > would work out okay. Depends whether having the -rX part of the package |
27 |
> > name is really important or not. |
28 |
> |
29 |
> I'd say it is important because -rX releases may have added |
30 |
> functionality/features that some may not want, etc. |
31 |
|
32 |
Then let's ask Tad to put ${PF} into the GLEP. |
33 |
|
34 |
> >> Otherwise, this seems ok to me and is easy to implement in the eclass. |
35 |
> > |
36 |
> > Good-o. So the two of us (ominously quiet in here ;-) are in agreement |
37 |
> > then? Oh, thought it was too good to be true ;-) |
38 |
> |
39 |
> It could happen! |
40 |
|
41 |
Lots of laughter. |
42 |
|
43 |
> > Shrugs. I just picked 'public_html' because it's a recognised convention |
44 |
> > (although not the only one I'm sure). 'public' is too generic for my |
45 |
> > liking. 'cgi-bin' *is* a recognised convention, and one we shouldn't |
46 |
> > break. |
47 |
> |
48 |
> I thought those were apache conventions. It really doesn't matter one way |
49 |
> or another. :-) |
50 |
|
51 |
Let's stick with 'public_html' and 'cgi-bin' then. |
52 |
|
53 |
> checking...still checking...done! It could probably be simplified to |
54 |
> something like the following: (I'm just the nitpick mongrel, aren't I?) |
55 |
> |
56 |
> if [ "`has_version '=net-www/apache-2*'`" -a "`use apache2`" ] ; then |
57 |
> APACHEVER=2 |
58 |
> elif [ "`has_version '=net-www/apache-1*'`" ] ; then |
59 |
> APACHEVER=1 |
60 |
> else |
61 |
> # no apache version detected |
62 |
> return 1 |
63 |
> fi |
64 |
|
65 |
According to the description in profiles/use.desc ... |
66 |
|
67 |
"apache2 - Chooses Apache2 support when a package supports both Apache1 |
68 |
and Apache2" |
69 |
|
70 |
With your version, if the user has Apache2 support, but doesn't have 'apache2' |
71 |
in the USE flags, no apache version will be detected. That doesn't seem to |
72 |
match the description in profiles/use.desc. |
73 |
|
74 |
> No offense taken of course. Lets just evolve yours overtime to do |
75 |
> everything that's needed because, as you say, it is already in portage. :-) |
76 |
|
77 |
Tbh, I wouldn't be surprised (or upset - I'm not the possessive type) if the |
78 |
eclass I've added to portage has to go when we implement this GLEP. |
79 |
|
80 |
Last night on IRC, I offered to TaD to code up a new eclass to provide a |
81 |
demonstration implementation of that part of the GLEP. Very earliest I could |
82 |
do this would be sometime next week, as I'm away for a long weekend from |
83 |
Thursday. |
84 |
|
85 |
Take care, |
86 |
Stu |
87 |
-- |
88 |
Stuart Herbert stuart@g.o |
89 |
Gentoo Developer http://www.gentoo.org/ |
90 |
Beta packages for download http://dev.gentoo.org/~stuart/packages/ |
91 |
|
92 |
GnuGP key id# F9AFC57C available from http://pgp.mit.edu |
93 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
94 |
-- |