From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-5232-arch-gentoo-dev=gentoo.org@gentoo.org> Received: (qmail 29225 invoked by uid 1002); 3 Aug 2003 19:45:24 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-dev@gentoo.org> List-Help: <mailto:gentoo-dev-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 4841 invoked from network); 3 Aug 2003 19:45:23 -0000 From: Stuart Herbert <stuart@gentoo.org> Reply-To: stuart@gentoo.org To: Max Kalika <max@gentoo.org>, Troy Dack <tad@gentoo.org>, gentoo-dev@gentoo.org Date: Sun, 3 Aug 2003 20:43:10 +0100 User-Agent: KMail/1.5.3 References: <1059843010.5023.80.camel@carbon.internal.lan> <200308031843.10426.stuart@gentoo.org> <2147483647.1059912184@[192.168.26.4]> In-Reply-To: <2147483647.1059912184@[192.168.26.4]> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_ZXWL/nQjA7FP0JO"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200308032043.21287.stuart@gentoo.org> Subject: Re: [gentoo-dev] [GLEP] Web Application Installation X-Archives-Salt: 2263bfe9-f7aa-41e5-b5b8-9417e427b039 X-Archives-Hash: 019ca875ccb33bb53c2443afc857aaec --Boundary-02=_ZXWL/nQjA7FP0JO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Sunday 03 August 2003 8:03 pm, Max Kalika wrote: > Chugga chugga chugga! :-) Lots of laughter. > You're absolutely right, and in fact this is what the eclass does right n= ow > (as shown by the example I posted earlier). ;-) > > Thanks for the example - it helps a great deal. Now, how would you deal > > with a site needing to run two copies of horde under the one web serve= r? > > Hmm. This depends on the app. Some apps have virtual hosting built-in > others do not. Those that do not, may need some sysadmin intervention, > doing some parallel installs, symlinking, what-have-you. I think we need > to have a limit to how much we can do at install time and how much we can > configure for the user out-of-the-box. For example, we don't have any way > of having two postfix instances installed and running on the same box with > the ebuild, but the sysadmin can go ahead and configure the installed > product to achieve the needed functionality. True. But most webapps will rely on the webserver to handle the virtual=20 hosting side of things - and that's something we *can* support through=20 user-space tools. > > Yeah - but how do you handle sites (like ISPs) that need to run multiple > > installations of the same app on the same box? You can't have a single > > globla configuration file for that. Makes sense for the home user, but > > not for ISPs. > > Continuing from above, it seems best left to the systems admin in designi= ng > how to implement virtual hosting. For example, horde has built-in virtual > hosting where you specify multiple servers and the specific one gets chos= en > based on the server hostname. Of course this isn't foolproof as things > like SSL will break it, but in any case, this decision has to be left to > the person installing it. It seems like the gentoo philosophy is to insta= ll > the necessary minimum to have a running product and leave the major > tinkering to the admin. =20 Quoting www.gentoo.org again, the phrase 'automatically configured' can be= =20 found. Where we can do a sensible minimum, I think we should. > 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 somethin= g=20 that you can safely put in cron. > Ok. If there's a lot of language-specific work that needs to be done, th= en > 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=20 achieving the same piece of testing. And on that note ... (drum roll please) ... take a look at the new=20 webapp-apache.eclass file that I've just committed to CVS. All it does (fo= r=20 now) is provide a standardised way of determine where HTDOCSDIR is, and whi= ch=20 Apache version to install support for. I admit it's a stop-gap solution; it's not enough on its own to make ebuild= s=20 webserver-neutral. But at least we can move all the apache-specific crud=20 into the one place, as a starter for ten. Yeah, okay, I'm jumping ahead of the GLEP being approved perhaps, but I nee= ded=20 this to close two outstanding bugs this afternoon, so that's my justificati= on=20 <grin>. Not exactly like I've gone and moved stuff into the proposed=20 'web-???' categories yet ;-) > 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 ve= ry=20 firm ideas about what he wanted to implement. > > How do you make an app install on (say) Zeus or (say) iPlanet or (say) > > n.e.other web server if the ebuild itself is server-specific? We're > > boxing ourselves in, for no good reason. > > No idea. :-) Exactly ;-) This is the problem that I think we should be solving. Anyway, take a look at the eclass, and let's talk about what else needs add= ing=20 to it - and let's get it added. =20 A word of warning - although the eclass is called 'webapp-apache', it's=20 designed to *hide* apache-specificness as much as possible behind its=20 interface. If you add anything to the eclass, I'd appreciate it if you=20 followed this design idea ;-) Robin (if you're following this!) I think you could make mod_php inherit th= is=20 class safely too, to reduce duplication still further. Take care, Stu =2D-=20 Stuart Herbert stuart@gentoo.o= rg Gentoo Developer http://www.gentoo.or= g/ Beta packages for download http://dev.gentoo.org/~stuart/package= s/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint =3D 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C =2D- --Boundary-02=_ZXWL/nQjA7FP0JO Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/LWXZDC+AuvmvxXwRAsOMAKCep8ixCswUJzIi+o/bfDRHf3SXpwCfXGzf v34f/KpNOoK9egS49v3G8wg= =CqDU -----END PGP SIGNATURE----- --Boundary-02=_ZXWL/nQjA7FP0JO--