* Re: [gentoo-dev] [GLEP] Web Application Installation
@ 2003-08-05 11:19 99% ` Stuart Herbert
0 siblings, 0 replies; 1+ results
From: Stuart Herbert @ 2003-08-05 11:19 UTC (permalink / raw
To: Paul de Vrieze, gentoo-dev
[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 4706 bytes --]
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
--
[-- 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-04 23:16 [gentoo-dev] [GLEP] Web Application Installation Max Kalika
2003-08-05 0:14 ` Stuart Herbert
2003-08-05 9:34 ` Paul de Vrieze
2003-08-05 11:19 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