From owner-freebsd-www Mon Apr 14 13:44:08 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA13187 for www-outgoing; Mon, 14 Apr 1997 13:44:08 -0700 (PDT) Received: from originat.demon.co.uk (originat.demon.co.uk [158.152.220.9]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA13154 for ; Mon, 14 Apr 1997 13:43:57 -0700 (PDT) Received: (from paul@localhost) by originat.demon.co.uk (8.8.5/8.6.9) id VAA23835 for www@freebsd.org; Mon, 14 Apr 1997 21:47:50 +0100 (BST) Resent-Message-Id: <199704142047.VAA23835@originat.demon.co.uk> Resent-To: www@freebsd.org Resent-From: Paul Richards Resent-Date: 14 Apr 1997 21:47:50 +0100 X-From-Line: nobody Mon Apr 14 21:46:04 1997 To: cracauer@wavehh.hanse.de (Martin Cracauer) Subject: Re: Comments on new search page.. References: <9704141757.AA05465@wavehh.hanse.de> From: Paul Richards Date: 14 Apr 1997 21:46:01 +0100 In-Reply-To: cracauer@wavehh.hanse.de's message of Mon, 14 Apr 1997 19:57:11 +0200 (MET DST) Message-ID: <87ragd2v06.fsf@originat.demon.co.uk> X-Mailer: Gnus v5.3/Emacs 19.34 Lines: 95 Xref: originat.demon.co.uk sent-1997-04:4 X-Gnus-Article-Number: 4 Mon Apr 14 21:46:04 1997 Sender: owner-freebsd-www@freebsd.org X-Loop: FreeBSD.org Precedence: bulk cracauer@wavehh.hanse.de (Martin Cracauer) writes: > A few comments: > > 1) We should not copy tools that are in src/ to www/ as well. CVS > doesn't support a concept like symbolic links, so we can't have both > without a maintainace nightmare and we can't have just www/ , because > the normal FreeBSD src/ build should install those tols as before. Maybe, maybe not. Not quite a directly related question but are all the mirrors FreeBSD boxes? I'd guess so but it's not necessarily the case. > This doesn't mean we should have no programs in www/ at all. Programs > that are needed by the HTML build process, but that should not be > parts of a normally installed FreeBSD system goes into www/. Programs > for all FreeBSD installations go into src/. A third category are > ports, but I think we can require having the newest version of a port > installed normally on a WWW mirror (if it build on older releases, > that is :-) We should think a bit about this. As far as possible it would be nice to not have to duplicate source trees but we also need to detach the www area from dependance on FreeBSD itself because the needs of www will move much faster than those of FreeBSD. It's essential that we have Perl5 for instance. If we're sure of the FreeBSD version that the mirror runs on then, yes, we can use the system binaries when possible, but in a heterogenous environment my experiences of doing this are all bad and it's much better to build the environment of the web product along with the product. This imposes constraints on the cgi scripts, not in what they can do but in how they should be written. As far as possible they should *not* use system binaries but rely on Perl functionality. It's rare that you need to use a system binary (in a complex journal delivery product in work I've not had one single need to use a system binary). This is true regardless of whether Perl5 is used but I'd hope that mainly that's what would be used. > 2) I think your setup require one installation procedure more than > needed. /product/FreeBSD/build is not needed. > > I like my idea of fully relative build more (obviously :-) and to have > just an install target that puts the WWW things (but not tools to > build these) where the httpd expects it. You don't install the tools on the web server. Only what's under ./content/ is installed on the web server. You have to create a build environment though in order to "build" the content. I think you may be confused by my use of the word build. In my example the build area is where the scripts used to build the site are placed. These are, for example, perl scripts for converting man pages into html. These never get installed on the web server (the web server is coceptually a different environment even if it's the same hardware). It's akin to the two steps of building the FreeBSD documentation. You first have to build the tools that are needed to "build" the documents. > The only problem I see is with libraries needed by tools. If we have a > C program that links to a non-standard library, we need to set up an > additional Makefile target so that it is linked to ../lib/whatever.a > instead of /usr/lib/whatever.a. Maybe it is acceptable to do this by > the standard FreeBSD build process as well. A web site that relies on relative links to make it portable are a nightmare to maintain. You can't easily restructure the site without a lot of effort. It's a much better paradigm to build a web site specifically for a target area and build it absolute. If you need to install it somewhere else you rebuild it for that target. > Same applies for perl modules, but those need to be current in the > base system anyway when CGI scripts are to be supported. I'm not a > perl expert, can one change the place perl looks for modules in by > environment variables? You can manipulate Perl's search path. The common trick is to set up the path in a BEGIN block e.g. BEGIN { push(@INC, "/www/FreeBSD/content/libs"); } -- Dr Paul Richards, Originative Solutions Ltd. Internet: paul@originat.demon.co.uk Phone: 0370 462071 (UK Mobile)