Hi Paul,

Thanks for joining in.  I was getting worried that this was turning into the 
'Max & Stuart Show' ;-)

Here's my rambling thoughts about how the 'local' USE flag (can we call it 
'-vhosts' instead? 'local' feels a bit non-descript to me) could work, and 
what problems might occur.  I'm sure that my thoughts here aren't the only 
possible solution.

Under the '+vhosts' approach, webapps would be SLOT'd, and would go into

	/usr/share/webapps/${PF}/

and users would have to use the -config toolset to then make the app available 
inside one or more vhosts.

What would happen in the '-vhosts' world?

I think it all pivots around one crucial design decision.  In the '-vhosts' 
world, do we want 'emerge -u' to be all that the user has to do (i.e. no need 
for the -config toolset)?  If not, then I can't see what '-vhosts' would 
actually do, and I'd suggest dropping it.

Let's explore what changes the 'emerge -u' objective might have to bring into 
the design.

I think that SLOT'ing webapps would have to be switched off when '-vhosts' is 
in effect.  Can we dynamically change the SLOT value inside an ebuild without 
upsetting Portage?  Let's assume we can for the moment.

I think the webapp would have to be installed directly under the 
'DocumentRoot' (/home/httpd/htdocs currently for Apache), instead of 
/usr/share/webapps/.  Would this create support hell if a user then wanted to 
move to vhosting on the same box?  emerge -C <webapp> will clean up 
correctly, so I'm not worried about that.  I think we could live with this.

As for config-protecting a webapp's configuration files, I'd do it by making 
the eclass add the config files to the CONFIG_PROTECT mask somehow.  The 
webapp ebuild needs to be able to identify the package's config files as part 
of the '+vhosts' solution, so the information would be available.  But I 
wonder if we'd need a change to Portage to allow the eclass to dynamically 
add these files to the CONFIG_PROTECT mask.  It wouldn't need to be a 
permanent addition - in fact, I'd argue against it.

(Lots of laughter.  Just listening to the radio, and apparently the heatwave 
we're having right now is causing parts of one of our busiest motorways to 
melt).

Speaking of eclasses, one way to hide the differences of the +/-vhosts world 
from the ebuild is to handle the differences entirely in the eclasses.

	# webapp.ebuild
	inhert webapp-proxy

	# webapp-proxy.eclass
	use 'vhosts' && inherit webapp-vhosts || inherit webapp-simple

webapp-vhosts.eclass (or whatever it's called) would have to present the same 
interface (same functions w/ same parameters in) as webapp-simple.eclass.

Just some thoughts,
Stu
--
On Tuesday 05 August 2003 10:34 am, Paul de Vrieze wrote:
> Ok what about the following.
>
> The problem that is most existent in this case is the fact that you want
> the eclass to support almost every kind of use. That is nice indeed. But
> making things easy for single hostname smalltime servers, and for extensive
> virtual hosting supports with customized webservers etc. is complicated.
> Also in that case default apache configuration snippets don't make that
> much sense. I think a solution could be to introduce a "local" useflag that
> selects behaviour.
>
> If you have a simple webserver for personal use, you can just leave things
> as they are and you can just run the config script or take some simple
> actions and everything works. For the other case the configuration tool can
> be used to create instances of a webapp for different virtual servers. That
> tool would probably need some configuration file etc. and it might even
> perform changes to the CONTENTS file to make the instances being included
> in the ebuild (when removing). It could then also automatically change the
> slot of the installed package so that it does not automatically get
> removed.
>
> I think that should be able to keep both sides happy.
>
> Paul
>
> ps. one thing I want to add though is that for a simple installation I
> think the configuration files should be config-protected (how that is
> aranged I don't care), and for complex setups the instance configurations
> should also be protected in some way (but that might be handled by the
> tool)

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