From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3571 invoked by uid 1002); 3 Aug 2003 14:48:25 -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 31889 invoked from network); 3 Aug 2003 14:48:25 -0000 From: Stuart Herbert Reply-To: stuart@gentoo.org To: Max Kalika , Troy Dack , gentoo-dev@gentoo.org Date: Sun, 3 Aug 2003 15:46:22 +0100 User-Agent: KMail/1.5.3 References: <1059843010.5023.80.camel@carbon.internal.lan> <200308030052.10108.stuart@gentoo.org> <2147483647.1059852387@[192.168.26.4]> In-Reply-To: <2147483647.1059852387@[192.168.26.4]> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_+ASL/fbx0mn1gT7"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200308031546.22388.stuart@gentoo.org> Subject: Re: [gentoo-dev] [GLEP] Web Application Installation X-Archives-Salt: c008c10b-8c61-4a0e-a02e-c3dba9ae3de3 X-Archives-Hash: 39e44a9bee340e47ef9eac344387e397 --Boundary-02=_+ASL/fbx0mn1gT7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Hi Max, On Sunday 03 August 2003 3:26 am, Max Kalika wrote: > > I'd prefer /etc/webapps//, again for future flexibility > > where a web application has more than one configuration file. I don't > > mind frigging apps to look in more than one place for a config file. I > > do mind patching apps to use just the one file. > > You want to mix the apache config block with other configuration files th= at > come with the application? =20 /etc/webapps// is the directory for the *application's* config= =20 files. Nothing to do with Apache per se. There is an alternative that should be considered. Maybe there shouldn't b= e=20 an /etc/webapps directory at all, and the config files should live under th= e=20 Document Root. Yes, this might be better. How would you support multiple= =20 installations of phpMyAdmin using a /etc/webapps/ scheme? > Yes! Which is why a patch is probably not always appropriate -- sed is > more resilient to pieces of configuration moving around upstream. Not sure I understand you here. A patch is applied against a known set of= =20 files. Portage only installs known sets of files. So a patch is no less=20 appropriate than sed. > > If Robin doesn't beat me to it, I'll write a script that we can add to > > Portage to standardise getting this information. > > What did you have in mind to achieve this? Last night, I thought I was sure. Unfortunately, waking up today I've=20 forgotten ;-) I'll go back and re-read the thread. > > What shape are other languages in for their dependencies? Not every > > webapp is going to be written in PHP ... > > Many apps are CGIs. Others can of course be mod_perl, mod_python, java, > you name it. I see no problems using the eclass with these because it was > written with flexibility in mind. Like I've said in the past. My initial > idea for this was to fix nut and apcuspd to cleanly install their CGI > components. We're going to use the one eclass for CGIs, mod_perl-dependent,=20 mod_python-dependent, and so on? Mmmm. That way lies pain and misery me=20 thinks. I think we'll need a webapps-base eclass, and then a webapps- set= of=20 eclasses. All the language-neutral stuff goes in the base, and everything= =20 else goes into each specific language eclass. > > Well, write access to directories under htdocs at any rate. TikiWiki - > > which we're looking to use for a Gentoo website - has this annoying > > feature. > > What bothers me though, is that having any directory under /usr writeable > is really bad form (I made a policy at work for all servers -- configure a > system where /usr can be mounted read-only). If at all possible, I'd like > to have these directories created under something like /var/lib/ and > symlinked back to where the app needs to write. If not symlinked then an > Apache alias (or whatever is equivalent to other servers). Writable /usr is something I'll have no part in. I thought Robin's idea was this. The master copy of the app goes in=20 /usr/webapps. Then we have a script that symlinks in the app under the=20 Document Root as required by the local admin, or uses .htaccess tricks as=20 appropriate. Robin - can you explain your idea again plz? > See above. But I agree, we _can't_ standardize on the approach simply > because it depends on what needs to be done. I imagine that there will be > some apps where we would just have complete config files living in > ${FILESDIR} that get installed over the ones that come with the package. Urgh. Only if the patch is larger than the replacement file, I'd hope ;-) > Having said that, I say we _should_ standardize on installation of packag= es > from the same family (i.e. Horde). Well, that'd be up to the maintainer of the packages I'd hope. > >> Standardization should always be applauded. :-) > > > > Urgh ;-) If everything in life was standardised, we'd be running RedHa= t, > > not busy upsetting the apple-cart with this upstart project ;-) > > Having run redhat for the past 4 years, I can safely say that that pile of > stuff strewn loosely together with twine and masking tape into a > nightmarish packaging system is far from standardized. Lots of laughter. My intention wasn't to start a RedHat flame war ;-) > Forgot to bring this up. Can't agree more. Web-* makes sense to me. > There's a slew of things that can go into web-mail and web-net just to > start. Definitely. > > Secondly, are we going to establish a webapps herd to look after the > > packages that will be added? If so, feel free to add me to the list of > > maintainers. If not, then what solution do you suggest? > > A herd makes sense. I'll leave this to the higher-ups thought. :-) As I understand it, if there's a group of us want a herd, then it's up to u= s=20 to put it in place and make it a success. > As I've said before many times, I'd like to see the eclass grow into > something that can be used with all the webservers we have in portage. I > don't know if userland tools can be flexible enough to create config bloc= ks > for all the apps that we're going to have. An ebuild knows enough of the > application to pass the necessary information to the eclass to create > whatever config is needed. At the same time, we have to be careful to not > balloon this into something unmaintainable. Which is why it may be best to > start this as apache-only (as it is the more popular of the webservers). > Get everything converted over and working and only then add support for > others. Just what webserver-specific configuration do these apps need? I'd hope th= at,=20 for the vast majority of apps, it's little to none. If we start down the apache-only route now, it's something that'll probably= =20 never get fixed. Let's identify just what apache config stuff you think is= =20 needed, and let's generalise it now. It can't be that difficult - it's onl= y=20 a web server. 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=_+ASL/fbx0mn1gT7 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/LSA+DC+AuvmvxXwRAp5JAKCx3bduXola47N0HZ5DyT51tqoHywCfQCLc 5bvIZdiF92s3lM8fercyXAI= =kDgq -----END PGP SIGNATURE----- --Boundary-02=_+ASL/fbx0mn1gT7--