[gentoo-dev] Implementing GLEP #11: webapp.eclass rev1 available for review

[Stuart Herbert]

Hi everyone,

Sorry that this is a bit lengthy, but there's a fair bit to cover for those 
who are interested in this ...

I've just committed the first (and untested!) webapp.eclass into Portage, so 
that all interested parties can see my initial thoughts on how we could 
handle ebuilds.

Please note: if you actually want to *run* webapp.eclass, you need to place 
the attached 'webapp-config.sh' file into /usr/share/webapp-config/ first.  
This file will be supplied by the webapp-config package when I'm ready to 
commit that to CVS.

Please note: I'm making this available for REVIEW.  It's certainly not here 
for us to start porting web-based applications to ;-)  We need something to 
kick off implementing GLEP #11, so here you go.  I'm sure that the final 
version will look quite different, and the best way to do that is to get as 
many people as possible looking at it.

How it's supposed to work: The key idea here is that ebuilds will no longer 
install web-based applications directly into anywhere.  As discussed in GLEP 
#11, we're moving to a two-stage install process.  The job of the ebuild is 
now to install web-based applications into /usr/share/webapps/, so that a 
tool called webapp-config can then install the web-based application into the 
htdocs directory of your choice later.

As part of this, the ebuild needs to provide extra information about the files 
to be installed.  The extra information includes:

1) which files need to be owned by the webserver's user:group combo (for 
write-access purposes).  All other files will be owned by another user (to be 
determined; perhaps root, but perhaps not)
2) script files executed by the webserver.  Normally, the relevant 
mod_php/mod_perl/mod_ruby would handle these, but we need to know what they 
are in case we provide PHP/CGI and so on in the future.
3) config files - files that need to be unique when second part of the 
two-stage install process kicks off.  Files not on this list will be made 
available to the webserver via smoke and mirrors instead ;-)

I'm sure that we'll need to add to this list when we start converting ebuilds 
en-masse across to the final solution.

I've attached a (in-progress!) ebuild for tikiwiki-1.7.1.1, to show how I see 
it working.

NOTE: I said this is a two-stage process.  If 'vhosts' is NOT in the USE 
flags, the eclass automagically kicks off the second stage of the process, so 
that (when the time comes) existing install behaviour remains.

At the moment, I'm working on a first-cut of the webapp-config tool.  It'll be 
a bash script at first.  Once the behaviour, and the interface in is stable, 
I'm thinking of recoding it in something else, so that it can be installed 
setuid root.

Max - I'd really appreciate your comments in particular.  You've put a lot of 
work into the Horde stuff, and I'm sure I haven't covered it all yet ;-)

I've opened bug #30607 for tracking all the feedback about this work.  Please 
post there, rather than reply to this.

Thanks,
Stu
-- 
Stuart Herbert                                              stuart@g.o
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/
Come and meet me in March 2004                 http://www.phparch.com/cruise/

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