* Re: [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-04 4:29 99% ` Max Kalika
0 siblings, 0 replies; 1+ results
From: Max Kalika @ 2003-08-04 4:29 UTC (permalink / raw
To: stuart, Max Kalika, Troy Dack, gentoo-dev
I don't know if I'm being overly abrasive -- the weather is really hot, and
I think I ate something that didn't agree with me. Please don't take
offense at anything I say. :-)
Quoting Stuart Herbert <stuart@gentoo.org>:
> On Sunday 03 August 2003 8:03 pm, Max Kalika wrote:
> True. But most webapps will rely on the webserver to handle the virtual
> hosting side of things - and that's something we *can* support through
> user-space tools.
Eh? Elaborate please.
>> Going back to the postfix example, although the
>> package has support for delivering mail to LMTP through a content filter
>> that will scan for spam and viruses, it doesn't do it out of the box and
>> takes a bit of tinkering to get right. I'm of the opinion that if
>> someone wants to set up an ISP, they better know what they're doing and
>> will be able to figure out how to virtualize the necessary packages they
>> want to offer to their clients.
>
> Problem with that is that it prevents 'emerge -u world' from being
> something that you can safely put in cron.
How is that? Aside from the fact that no sysadmin who values his/her job
would do this on a production system, I don't see why this would be a
problem/impediment?
>> Ok. If there's a lot of language-specific work that needs to be done,
>> then breaking it up into separate eclasses makes sense, otherwise, I'm
>> worried about clutter. :)
>
> Yeah, clutter is a problem - but so is ten ebuilds each with their own
> way of achieving the same piece of testing.
Correct, which is what eclasses are for.
> And on that note ... (drum roll please) ... take a look at the new
> webapp-apache.eclass file that I've just committed to CVS. All it does
> (for now) is provide a standardised way of determine where HTDOCSDIR is,
> and which Apache version to install support for.
Ugh! Won't this get in the way when we actually try to implement this GLEP
(most of which is already done by my eclass). The way you did it has
already been tried and shot down:
<http://www.gentoo.org/cgi-bin/viewcvs.cgi/eclass/Attic/apache.eclass?hidea
ttic=0>
> I admit it's a stop-gap solution; it's not enough on its own to make
> ebuilds webserver-neutral. But at least we can move all the
> apache-specific crud into the one place, as a starter for ten.
Double Ugh! See these please:
<http://marc.theaimsgroup.com/?l=gentoo-dev&w=2&r=1&s=apache.eclass&q=b>
> Yeah, okay, I'm jumping ahead of the GLEP being approved perhaps, but I
> needed this to close two outstanding bugs this afternoon, so that's my
> justification <grin>. Not exactly like I've gone and moved stuff into
> the proposed 'web-???' categories yet ;-)
See, this GLEP was more about where/how to install these ebuilds and not
about their place in the tree. I held off including at least 10 ebuilds
waiting for the outcome of this discussion, but now you jumped the gun.
Hopefully the transition can be painless.
>> Fair enough. So something like "webapp-config <application>
>> <webserver>" ?
>
> I think so, yeah. Robin's the best person to talk about this, as he had
> very firm ideas about what he wanted to implement.
Will wait for Robin's response.
> Exactly ;-) This is the problem that I think we should be solving.
Well, perhaps a question in the original GLEP should be readdressed. I'm
beginning to strongly agree with:
# 1. Default Web Server
# ---------------------
# A common default web server will have to be selected and ebuild authors
# should ensure that their applications contain configuration directives
# suitable for that server. Given the popularity of the Apache web server
# it is suggested that Apache be selected as the Gentoo default web server.
# Whilst it is acknowledged that other web servers do exist and are used,
# there has to be an assumption made somewhere that people who choose to
use
# something other than a default have enough knowledge to adapt
# configurations accordingly.
Flexibility is one thing, maintainability with a limited developer time is
quite another. The balance between the two is critical.
> Anyway, take a look at the eclass, and let's talk about what else needs
> adding to it - and let's get it added.
I did. It looks like a trimmed version of the original proposed by Ned
Ludd.
> A word of warning - although the eclass is called 'webapp-apache', it's
> designed to *hide* apache-specificness as much as possible behind its
> interface. If you add anything to the eclass, I'd appreciate it if you
> followed this design idea ;-)
But you completely ignored all my work and the GLEP which we're discussing.
My eclass follows your proposed philosophy, but you basically threw it out
the window. I'm confused.
> Robin (if you're following this!) I think you could make mod_php inherit
> this class safely too, to reduce duplication still further.
How is mod_php related to the way applications are installed?
--mk
--
gentoo-dev@gentoo.org mailing list
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
2003-08-03 17:43 ` Stuart Herbert
2003-08-03 19:03 ` Max Kalika
2003-08-03 19:43 ` Stuart Herbert
2003-08-04 4:29 99% ` Max Kalika
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox