| 1 |
First off - thank you Troy for getting this moving. Nice one ;-) |
| 2 |
|
| 3 |
On Sunday 03 August 2003 12:11 am, Max Kalika wrote: |
| 4 |
> > * for files to be served to clients:: |
| 5 |
> > |
| 6 |
> > /usr/share/webapps/<application>/files/ |
| 7 |
> |
| 8 |
> I think this should just be /usr/share/webapps/<application>/ |
| 9 |
|
| 10 |
Sorry, but I very strongly disagree. Not every web application needs all its |
| 11 |
files to be accessable via a web browser. |
| 12 |
|
| 13 |
/usr/share/webapps/htdocs/ for files that should be accessable via a web |
| 14 |
browser. This leaves room for any other files (PHP scripts are the one that |
| 15 |
comes to mind for me) to go into other sub-directories if required. |
| 16 |
|
| 17 |
(Confession: I do have a personal interest. I write web apps professionally, |
| 18 |
and none of them have the PHP files available for serving out via the web |
| 19 |
browser.) |
| 20 |
|
| 21 |
> The eclass currently puts them as /etc/webapps/<application>.conf. This |
| 22 |
> way they are parallel to the application configuration files and are also |
| 23 |
> web-server independent, all while being protected by CONFIG_PROTECT. The |
| 24 |
> ebuild informs the user to how to activate the installed app which, when |
| 25 |
> executed, |
| 26 |
> just creates a link into the already-configured apache directory. |
| 27 |
|
| 28 |
I'd prefer /etc/webapps/<application>/, again for future flexibility where a |
| 29 |
web application has more than one configuration file. I don't mind frigging |
| 30 |
apps to look in more than one place for a config file. I do mind patching |
| 31 |
apps to use just the one file. |
| 32 |
|
| 33 |
The less we have to patch an app, the less work we're going to make for |
| 34 |
ourselves - especially on the support side. |
| 35 |
|
| 36 |
> - Determining what modules mod_php has built into it. Currently, I have |
| 37 |
> a quick and dirty function in the webapp eclass called check_php() which |
| 38 |
> looks for a particular USE flag in /var/db/pkg/dev-php/mod_php*/USE. |
| 39 |
> This probably needs to be a bit cleaner. |
| 40 |
|
| 41 |
If Robin doesn't beat me to it, I'll write a script that we can add to Portage |
| 42 |
to standardise getting this information. |
| 43 |
|
| 44 |
W.r.t. PHP detection, we have two other problems: |
| 45 |
|
| 46 |
a) Depending on virtual/php is useless, because it doesn't guarantee that |
| 47 |
mod_php is installed (could be that PHP/CLI is installed) - unless you've |
| 48 |
already fixed this Robin? Anyway, it doesn't tell you what version of PHP is |
| 49 |
installed - and some apps need specific versions of PHP (yes, they're broken, |
| 50 |
but that doesn't mean we shouldn't support them). |
| 51 |
b) Depending on mod_php will break once PHP/CGI is added to Portage. Again, |
| 52 |
maybe Robin's already put something in place to deal with this (we've |
| 53 |
discussed it off-list in the past). |
| 54 |
|
| 55 |
What shape are other languages in for their dependencies? Not every webapp is |
| 56 |
going to be written in PHP ... |
| 57 |
|
| 58 |
> - Certain web applications need to have write access to the directory |
| 59 |
> where they are installed (curse them!) :-) |
| 60 |
|
| 61 |
Well, write access to directories under htdocs at any rate. TikiWiki - which |
| 62 |
we're looking to use for a Gentoo website - has this annoying feature. |
| 63 |
|
| 64 |
> - Great care must be taken to properly prepare the configuration files. |
| 65 |
> For example, Horde config files have paths defined relative to the |
| 66 |
> config file itself so some sed magic was used to fix a lot of it. |
| 67 |
|
| 68 |
You use sed, I'd apply patches, and I'm sure there's other ways too that |
| 69 |
people would like to use. So long as they get the right result, I don't |
| 70 |
think we need to standardise on the approach. |
| 71 |
|
| 72 |
> Standardization should always be applauded. :-) |
| 73 |
|
| 74 |
Urgh ;-) If everything in life was standardised, we'd be running RedHat, not |
| 75 |
busy upsetting the apple-cart with this upstart project ;-) |
| 76 |
|
| 77 |
Two other things I want to chuck in, if I can. |
| 78 |
|
| 79 |
First off, where are webapp ebuilds going to live in Portage? I'd like to see |
| 80 |
a set of 'web-???' categories myself, so that web apps are clearly visible |
| 81 |
and easy to find. I don't think they should disappear under 'net-www' or |
| 82 |
into various 'app-???' directories. |
| 83 |
|
| 84 |
Secondly, are we going to establish a webapps herd to look after the packages |
| 85 |
that will be added? If so, feel free to add me to the list of maintainers. |
| 86 |
If not, then what solution do you suggest? |
| 87 |
|
| 88 |
I think the ebuilds for web apps should be ENTIRELY webserver neutral. This |
| 89 |
is why I've done nothing with Max's eclass myself. There should be userland |
| 90 |
tools for creating an instance of an app under Apache or whatever. Yes, I |
| 91 |
know that most people will run Apache, and not care about this, but Gentoo's |
| 92 |
supposed to be about configurability. We have a chance to get some solid |
| 93 |
foundations in - I say let's get digging. |
| 94 |
|
| 95 |
Best regards, |
| 96 |
Stu |
| 97 |
-- |
| 98 |
Stuart Herbert stuart@g.o |
| 99 |
Gentoo Developer http://www.gentoo.org/ |
| 100 |
Beta packages for download http://dev.gentoo.org/~stuart/packages/ |
| 101 |
|
| 102 |
GnuGP key id# F9AFC57C available from http://pgp.mit.edu |
| 103 |
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C |
| 104 |
-- |
Archives