* Re: [gentoo-dev] Re: [gentoo-core] [GLEP] Web Application Installation
@ 2003-08-02 23:51 99% ` Stuart Herbert
0 siblings, 0 replies; 1+ results
From: Stuart Herbert @ 2003-08-02 23:51 UTC (permalink / raw
To: Max Kalika, Troy Dack, gentoo-dev
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 4962 bytes --]
First 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/<application>/files/
>
> 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 accessable via a web browser.
/usr/share/webapps/htdocs/ for files that should be accessable 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.)
> The eclass currently puts them as /etc/webapps/<application>.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/<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.
The less we have to patch an app, the less work we're going to make for
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() which
> 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 Portage
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
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, they're broken,
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,
maybe Robin's already put something in place to deal with this (we've
discussed it off-list in the past).
What shape are other languages in for their dependencies? Not every webapp is
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 - which
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
people would like to use. So long as they get the right result, I don't
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, not
busy upsetting the apple-cart with this upstart project ;-)
Two other things I want to chuck in, if I can.
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.
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?
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.
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 --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2003-08-02 16:50 [gentoo-dev] [GLEP] Web Application Installation Troy Dack
2003-08-02 23:11 ` [gentoo-dev] Re: [gentoo-core] " Max Kalika
2003-08-02 23:51 99% ` Stuart Herbert
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox