Re: [gentoo-dev] [GLEP] Web Application Installation

[Stuart Herbert <stuart@gentoo.org>]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 6399 bytes --]

Hi Max,

On Sunday 03 August 2003 3:26 am, Max Kalika wrote:
> > I'd prefer /etc/webapps/<application>/, 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 that
> come with the application?  

/etc/webapps/<application>/ is the directory for the *application's* config 
files.  Nothing to do with Apache per se.

There is an alternative that should be considered.  Maybe there shouldn't be 
an /etc/webapps directory at all, and the config files should live under the 
Document Root.  Yes, this might be better.  How would you support multiple 
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 
files.  Portage only installs known sets of files.  So a patch is no less 
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 
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, 
mod_python-dependent, and so on?  Mmmm.  That way lies pain and misery me 
thinks.

I think we'll need a webapps-base eclass, and then a webapps-<language> set of 
eclasses.  All the language-neutral stuff goes in the base, and everything 
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 
/usr/webapps.  Then we have a script that symlinks in the app under the 
Document Root as required by the local admin, or uses .htaccess tricks as 
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 packages
> 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 RedHat,
> > 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 us 
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 blocks
> 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 that, 
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 
never get fixed.  Let's identify just what apache config stuff you think is 
needed, and let's generalise it now.  It can't be that difficult - it's only 
a web server.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]