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

[Max Kalika]

Quoting Stuart Herbert <stuart@g.o>:

> First off - thank you Troy for getting this moving.  Nice one ;-)

+1 :-)

> I think this should just be /usr/share/webapps/<application>/
>
> Sorry, but I very strongly disagree.  Not every web application needs all
> its  files to be accessible via a web browser.

Granted, but this means more changing in the core or config files of the
particular application.

> /usr/share/webapps/htdocs/ for files that should be accessible via a web
> browser.  This leaves room for any other files (PHP scripts are the one
> that  comes to mind for me) to go into other sub-directories if required.
>
> (Confession: I do have a personal interest.  I write web apps
> professionally,  and none of them have the PHP files available for
> serving out via the web  browser.)

Same here.

> 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?  Seems messy to me.  Especially if we're going
to be supporting multiple webservers (creating server-specific config
files).  Perhaps another directory where you can separate the
application-specific config files from server-specific ones.  Ideas?

> The less we have to patch an app, the less work we're going to make for
> ourselves - especially on the support side.

Yes!  Which is why a patch is probably not always appropriate -- sed is
more resilient to pieces of configuration moving around upstream.

> 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?

> W.r.t. PHP detection, we have two other problems:
>
> a) Depending on virtual/php is useless, because it doesn't guarantee that
> mod_php is installed (could be that PHP/CLI is installed) - unless you've
> already fixed this Robin?  Anyway, it doesn't tell you what version of
> PHP is  installed - and some apps need specific versions of PHP (yes,

I'll leave this to you all as you seem to have hashed this out already
between you.

> 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.

> 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). 

> You use sed, I'd apply patches, and I'm sure there's other ways too that
> people would like to use.  So long as they get the right result, I don't
> think we need to standardise on the approach.

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.
Having said that, I say we _should_ standardize on installation of packages
from the same family (i.e. Horde).

>> 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.

> First off, where are webapp ebuilds going to live in Portage?  I'd like
> to see  a set of 'web-???' categories myself, so that web apps are
> clearly visible  and easy to find.  I don't think they should disappear
> under 'net-www' or  into various 'app-???' directories.

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.

> 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. :-)

> I think the ebuilds for web apps should be ENTIRELY webserver neutral.
> This  is why I've done nothing with Max's eclass myself.  There should be
> userland  tools for creating an instance of an app under Apache or
> whatever.  Yes, I  know that most people will run Apache, and not care
> about this, but Gentoo's  supposed to be about configurability.  We have
> a chance to get some solid  foundations in - I say let's get digging.

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. 

--mk

--
gentoo-dev@g.o mailing list