From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13246 invoked by uid 1002); 5 Aug 2003 21:00:56 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 21006 invoked from network); 5 Aug 2003 21:00:56 -0000 Date: Tue, 05 Aug 2003 14:00:54 -0700 From: Max Kalika To: stuart@gentoo.org, Paul de Vrieze , gentoo-dev@gentoo.org Message-ID: <12930000.1060117254@valkyrie.lsit.ucsb.edu> In-Reply-To: <200308051219.49435.stuart@gentoo.org> References: <86960000.1060038977@valkyrie.lsit.ucsb.edu> <200308050114.29952.stuart@gentoo.org> <200308051134.46249.pauldv@gentoo.org> <200308051219.49435.stuart@gentoo.org> X-Mailer: Mulberry/3.0.3 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: [gentoo-dev] [GLEP] Web Application Installation X-Archives-Salt: ac3b0927-d8c1-45de-822c-49eae351225f X-Archives-Hash: d4a84ba9852df3b764ead535279e858b Quoting Stuart Herbert : > Thanks for joining in. I was getting worried that this was turning into > the 'Max & Stuart Show' ;-) Can we get a time slot on FOX? I'm thinking 9:12AM. :-) > Under the '+vhosts' approach, webapps would be SLOT'd, and would go into > > /usr/share/webapps/${PF}/ Just the SLOTed? Or all the webapps? Why not all? > 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. I don't think we want emerge -u to touch anything other than the central install. > 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 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. Is it really necessary to separate the whole virtual/local? Can we develop the -config tool to take the following syntax? # webapp-config The application can be specified by the currently supported portage syntax, i.e. =web-dev/horde-2* or >=web-mail/imp-3 or simply web-db/phpmyadmin. The tool then looks for a list of installed apps that match. If more than one is found it either bombs out or presents a choice menu. Otherwise it goes ahead and configures the destination_dir to contain the specified app. First it checks for existence of the app already in the destination. If nothing exists, we create the directory, and copy the core and conf files in. If the app already exists, we switch to "upgrade" mode where we overwrite all the core files and do dispatch-conf-type work to protect the config files. How do we know which files are config files and which are core files, I hear you asking? How about this: Either use the Portage API or look at the /var/db/pkg/$CATEGORY/$PF/CONTENTS file ourselves. 'obj' types stored in '/usr/share/webapp' (or $WEBAPP_DEST or whatever) are "core" files; 'obj' types stored in '/etc/webapps' (or $WEBAPP_ETC) are "conf" files. Everything else (docs, etc) doesn't need to go into the webserver space. So if this is how things work, there's no need to worry about what is a vhost and what is a single install. Also we don't have to be concerned where the DocRoot is -- the user just specifies the destination directory. I guess this is a very rough first-draft proposal for the webapp-config. I am probably missing major chunks, but this is a braindump of what I thought of so far. Flog me for anything blatantly erroneous. --mk -- gentoo-dev@gentoo.org mailing list