| 1 |
I don't know if I'm being overly abrasive -- the weather is really hot, and |
| 2 |
I think I ate something that didn't agree with me. Please don't take |
| 3 |
offense at anything I say. :-) |
| 4 |
|
| 5 |
Quoting Stuart Herbert <stuart@g.o>: |
| 6 |
|
| 7 |
> On Sunday 03 August 2003 8:03 pm, Max Kalika wrote: |
| 8 |
|
| 9 |
> True. But most webapps will rely on the webserver to handle the virtual |
| 10 |
> hosting side of things - and that's something we *can* support through |
| 11 |
> user-space tools. |
| 12 |
|
| 13 |
Eh? Elaborate please. |
| 14 |
|
| 15 |
>> Going back to the postfix example, although the |
| 16 |
>> package has support for delivering mail to LMTP through a content filter |
| 17 |
>> that will scan for spam and viruses, it doesn't do it out of the box and |
| 18 |
>> takes a bit of tinkering to get right. I'm of the opinion that if |
| 19 |
>> someone wants to set up an ISP, they better know what they're doing and |
| 20 |
>> will be able to figure out how to virtualize the necessary packages they |
| 21 |
>> want to offer to their clients. |
| 22 |
> |
| 23 |
> Problem with that is that it prevents 'emerge -u world' from being |
| 24 |
> something that you can safely put in cron. |
| 25 |
|
| 26 |
How is that? Aside from the fact that no sysadmin who values his/her job |
| 27 |
would do this on a production system, I don't see why this would be a |
| 28 |
problem/impediment? |
| 29 |
|
| 30 |
>> Ok. If there's a lot of language-specific work that needs to be done, |
| 31 |
>> then breaking it up into separate eclasses makes sense, otherwise, I'm |
| 32 |
>> worried about clutter. :) |
| 33 |
> |
| 34 |
> Yeah, clutter is a problem - but so is ten ebuilds each with their own |
| 35 |
> way of achieving the same piece of testing. |
| 36 |
|
| 37 |
Correct, which is what eclasses are for. |
| 38 |
|
| 39 |
> And on that note ... (drum roll please) ... take a look at the new |
| 40 |
> webapp-apache.eclass file that I've just committed to CVS. All it does |
| 41 |
> (for now) is provide a standardised way of determine where HTDOCSDIR is, |
| 42 |
> and which Apache version to install support for. |
| 43 |
|
| 44 |
Ugh! Won't this get in the way when we actually try to implement this GLEP |
| 45 |
(most of which is already done by my eclass). The way you did it has |
| 46 |
already been tried and shot down: |
| 47 |
|
| 48 |
<http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/Attic/apache.eclass?hidea |
| 49 |
ttic=0> |
| 50 |
|
| 51 |
> I admit it's a stop-gap solution; it's not enough on its own to make |
| 52 |
> ebuilds webserver-neutral. But at least we can move all the |
| 53 |
> apache-specific crud into the one place, as a starter for ten. |
| 54 |
|
| 55 |
Double Ugh! See these please: |
| 56 |
|
| 57 |
<http://marc.theaimsgroup.com/?l=gentoo-dev&w=2&r=1&s=apache.eclass&q=b> |
| 58 |
|
| 59 |
> Yeah, okay, I'm jumping ahead of the GLEP being approved perhaps, but I |
| 60 |
> needed this to close two outstanding bugs this afternoon, so that's my |
| 61 |
> justification <grin>. Not exactly like I've gone and moved stuff into |
| 62 |
> the proposed 'web-???' categories yet ;-) |
| 63 |
|
| 64 |
See, this GLEP was more about where/how to install these ebuilds and not |
| 65 |
about their place in the tree. I held off including at least 10 ebuilds |
| 66 |
waiting for the outcome of this discussion, but now you jumped the gun. |
| 67 |
Hopefully the transition can be painless. |
| 68 |
|
| 69 |
>> Fair enough. So something like "webapp-config <application> |
| 70 |
>> <webserver>" ? |
| 71 |
> |
| 72 |
> I think so, yeah. Robin's the best person to talk about this, as he had |
| 73 |
> very firm ideas about what he wanted to implement. |
| 74 |
|
| 75 |
Will wait for Robin's response. |
| 76 |
|
| 77 |
> Exactly ;-) This is the problem that I think we should be solving. |
| 78 |
|
| 79 |
Well, perhaps a question in the original GLEP should be readdressed. I'm |
| 80 |
beginning to strongly agree with: |
| 81 |
|
| 82 |
# 1. Default Web Server |
| 83 |
# --------------------- |
| 84 |
|
| 85 |
# A common default web server will have to be selected and ebuild authors |
| 86 |
# should ensure that their applications contain configuration directives |
| 87 |
# suitable for that server. Given the popularity of the Apache web server |
| 88 |
# it is suggested that Apache be selected as the Gentoo default web server. |
| 89 |
|
| 90 |
# Whilst it is acknowledged that other web servers do exist and are used, |
| 91 |
# there has to be an assumption made somewhere that people who choose to |
| 92 |
use |
| 93 |
# something other than a default have enough knowledge to adapt |
| 94 |
# configurations accordingly. |
| 95 |
|
| 96 |
Flexibility is one thing, maintainability with a limited developer time is |
| 97 |
quite another. The balance between the two is critical. |
| 98 |
|
| 99 |
> Anyway, take a look at the eclass, and let's talk about what else needs |
| 100 |
> adding to it - and let's get it added. |
| 101 |
|
| 102 |
I did. It looks like a trimmed version of the original proposed by Ned |
| 103 |
Ludd. |
| 104 |
|
| 105 |
> A word of warning - although the eclass is called 'webapp-apache', it's |
| 106 |
> designed to *hide* apache-specificness as much as possible behind its |
| 107 |
> interface. If you add anything to the eclass, I'd appreciate it if you |
| 108 |
> followed this design idea ;-) |
| 109 |
|
| 110 |
But you completely ignored all my work and the GLEP which we're discussing. |
| 111 |
My eclass follows your proposed philosophy, but you basically threw it out |
| 112 |
the window. I'm confused. |
| 113 |
|
| 114 |
> Robin (if you're following this!) I think you could make mod_php inherit |
| 115 |
> this class safely too, to reduce duplication still further. |
| 116 |
|
| 117 |
How is mod_php related to the way applications are installed? |
| 118 |
|
| 119 |
--mk |
| 120 |
|
| 121 |
|
| 122 |
-- |
| 123 |
gentoo-dev@g.o mailing list |
Archives