| 1 |
Ned Ludd wrote: |
| 2 |
>The means by which the DocumentRoot is found is actually pretty elegant |
| 3 |
>and the functionality of that can easily be placed in an eclass. I'd |
| 4 |
>consider this a big plus in terms of usability. As you're pointing out, |
| 5 |
>/var/www is the FHS compliant place to put the documentroot anyway, so |
| 6 |
>I'm not sure why we're being like RedHat in this respect. |
| 7 |
|
| 8 |
I would strongly advise you to get your facts straight before |
| 9 |
rolling through here muttering something like that. This is not |
| 10 |
correct. I'm afraid you need to do some remedial reading on the |
| 11 |
situation. |
| 12 |
|
| 13 |
You may want to visit http://www.pathname.com/fhs/ where you |
| 14 |
can learn that there *IS* no standard for this. And as such, |
| 15 |
the location in which to install Apache and other web-related |
| 16 |
files, is simply nothing more the opinion of the person you're |
| 17 |
currently talking to. The current FHS version doesnt address |
| 18 |
this area. I havent looked at any of the work in progress for |
| 19 |
FHS 2.3 by the way; perhaps there's new developments there? |
| 20 |
|
| 21 |
If you want even more standards, then please open your |
| 22 |
config.layout file, distributed with the Apache source code, |
| 23 |
and well, take your pick from several more "standards". |
| 24 |
|
| 25 |
>At the very least, why don't we make the httpd user's home directory |
| 26 |
>/var/www? Alas, if we did so we would still require detection routines |
| 27 |
>for currently installed systems. |
| 28 |
|
| 29 |
There are other reasons to use this location, but none of them |
| 30 |
to do with FHS. :-) |
| 31 |
|
| 32 |
As for the apache2 USE flag; I made it so that the mod_php |
| 33 |
ebuild didnt have to *guess* at which API to build the DSO |
| 34 |
for. I've talked with Robin about this, and we'd both very |
| 35 |
much like to see it "go away". It's nasty. |
| 36 |
|
| 37 |
|
| 38 |
Robin H.Johnson wrote: |
| 39 |
>Having both installed simultaneously is a very messy business already, |
| 40 |
>as they both use /home/httpd, and contain binaries with identical names. |
| 41 |
|
| 42 |
They are configured to serve from the same DocumentRoot. I |
| 43 |
didnt want to introduce *another* docroot. They'll overwrite |
| 44 |
some icons from the other's install. I assume those who |
| 45 |
really, really want those default ASF icons from the other |
| 46 |
version, can figure out howto get them from the tarball. |
| 47 |
Same for the default introduction pages. Is this a big |
| 48 |
deal? What binaries are you talking about? I took |
| 49 |
pains to SLOT=2 Apache2, Im not aware of any binaries |
| 50 |
getting overwritten. |
| 51 |
|
| 52 |
As for the eclass, it's obviously a natural progression. |
| 53 |
I have not attempted to create one yet because I dont |
| 54 |
really have a great idea for what functions it should |
| 55 |
provide. The very basic ones proposed were simply not |
| 56 |
enough to convince me to add this yet. If they were |
| 57 |
I would have added one months ago. What other functions |
| 58 |
would be desired from an web-related eclass? I'm not |
| 59 |
*completely* and outright opposed to the stuff proposed, |
| 60 |
Im just saying it's weak, and well, it certainly isnt |
| 61 |
a sic "way to totally and easily manage the whole |
| 62 |
Apache config" as somebody else mentioned. Far from |
| 63 |
it. |
| 64 |
|
| 65 |
Further, Im not of the opinion that having a "bonifide" |
| 66 |
location in which to install these files on a Gentoo |
| 67 |
system (/home/httpd/{htdocs,cgi-bin} is a BAD idea, |
| 68 |
and having them just the way they are now at least |
| 69 |
provides this. |
| 70 |
|
| 71 |
Donny. |
| 72 |
|
| 73 |
|
| 74 |
-- |
| 75 |
gentoo-dev@g.o mailing list |
Archives