From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26368 invoked by uid 1002); 2 Aug 2003 23:54:12 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 21620 invoked from network); 2 Aug 2003 23:54:12 -0000 From: Stuart Herbert Reply-To: stuart@gentoo.org To: Max Kalika , Troy Dack , gentoo-dev@gentoo.org Date: Sun, 3 Aug 2003 00:51:58 +0100 User-Agent: KMail/1.5.9.1i References: <1059843010.5023.80.camel@carbon.internal.lan> <2147483647.1059840689@[192.168.26.4]> In-Reply-To: <2147483647.1059840689@[192.168.26.4]> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_q6EL/fB8wokRnwJ"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200308030052.10108.stuart@gentoo.org> Subject: Re: [gentoo-dev] Re: [gentoo-core] [GLEP] Web Application Installation X-Archives-Salt: cd06e578-d5a0-4c4e-8388-57640378e132 X-Archives-Hash: 665597cb37293f9fd3556db8dba0a17a --Boundary-02=_q6EL/fB8wokRnwJ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline =46irst off - thank you Troy for getting this moving. Nice one ;-) On Sunday 03 August 2003 12:11 am, Max Kalika wrote: > > * for files to be served to clients:: > > > > /usr/share/webapps//files/ > > I think this should just be /usr/share/webapps// Sorry, but I very strongly disagree. Not every web application needs all i= ts=20 files to be accessable via a web browser. /usr/share/webapps/htdocs/ for files that should be accessable via a web=20 browser. This leaves room for any other files (PHP scripts are the one tha= t=20 comes to mind for me) to go into other sub-directories if required. (Confession: I do have a personal interest. I write web apps professionall= y,=20 and none of them have the PHP files available for serving out via the web=20 browser.) > The eclass currently puts them as /etc/webapps/.conf. This > way they are parallel to the application configuration files and are also > web-server independent, all while being protected by CONFIG_PROTECT. The > ebuild informs the user to how to activate the installed app which, when > executed, > just creates a link into the already-configured apache directory. I'd prefer /etc/webapps//, again for future flexibility where = a=20 web application has more than one configuration file. I don't mind friggin= g=20 apps to look in more than one place for a config file. I do mind patching= =20 apps to use just the one file. The less we have to patch an app, the less work we're going to make for=20 ourselves - especially on the support side. > - Determining what modules mod_php has built into it. Currently, I have > a quick and dirty function in the webapp eclass called check_php() whi= ch > looks for a particular USE flag in /var/db/pkg/dev-php/mod_php*/USE. > This probably needs to be a bit cleaner. If Robin doesn't beat me to it, I'll write a script that we can add to Port= age=20 to standardise getting this information. W.r.t. PHP detection, we have two other problems: a) Depending on virtual/php is useless, because it doesn't guarantee that=20 mod_php is installed (could be that PHP/CLI is installed) - unless you've=20 already fixed this Robin? Anyway, it doesn't tell you what version of PHP = is=20 installed - and some apps need specific versions of PHP (yes, they're broke= n,=20 but that doesn't mean we shouldn't support them). b) Depending on mod_php will break once PHP/CGI is added to Portage. Again= ,=20 maybe Robin's already put something in place to deal with this (we've=20 discussed it off-list in the past). What shape are other languages in for their dependencies? Not every webapp= is=20 going to be written in PHP ... > - Certain web applications need to have write access to the directory > where they are installed (curse them!) :-) Well, write access to directories under htdocs at any rate. TikiWiki - whi= ch=20 we're looking to use for a Gentoo website - has this annoying feature. > - Great care must be taken to properly prepare the configuration files. > For example, Horde config files have paths defined relative to the > config file itself so some sed magic was used to fix a lot of it. You use sed, I'd apply patches, and I'm sure there's other ways too that=20 people would like to use. So long as they get the right result, I don't=20 think we need to standardise on the approach. > Standardization should always be applauded. :-) Urgh ;-) If everything in life was standardised, we'd be running RedHat, n= ot=20 busy upsetting the apple-cart with this upstart project ;-) Two other things I want to chuck in, if I can. =46irst off, where are webapp ebuilds going to live in Portage? I'd like t= o see=20 a set of 'web-???' categories myself, so that web apps are clearly visible= =20 and easy to find. I don't think they should disappear under 'net-www' or=20 into various 'app-???' directories. Secondly, are we going to establish a webapps herd to look after the packag= es=20 that will be added? If so, feel free to add me to the list of maintainers.= =20 If not, then what solution do you suggest? I think the ebuilds for web apps should be ENTIRELY webserver neutral. Thi= s=20 is why I've done nothing with Max's eclass myself. There should be userlan= d=20 tools for creating an instance of an app under Apache or whatever. Yes, I= =20 know that most people will run Apache, and not care about this, but Gentoo'= s=20 supposed to be about configurability. We have a chance to get some solid=20 foundations in - I say let's get digging. Best regards, 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=_q6EL/fB8wokRnwJ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/LE6qDC+AuvmvxXwRAvB7AJ9iCugxNBEG6FeLh3Q3/m8dV4CpogCfYtR4 uefEeBhQ8hAi/3LcFUc90qc= =NF5I -----END PGP SIGNATURE----- --Boundary-02=_q6EL/fB8wokRnwJ--