Date: Tue, 15 Apr 1997 01:19:39 +0200 (MET DST) From: cracauer@wavehh.hanse.de (Martin Cracauer) To: paul@originat.demon.co.uk (Paul Richards) Cc: www@freebsd.org Subject: Re: Comments on new search page.. Message-ID: <9704142319.AA25408@wavehh.hanse.de> In-Reply-To: <87ragd2v06.fsf@originat.demon.co.uk> from "Paul Richards" at Apr 14, 97 09:46:01 pm
next in thread | previous in thread | raw e-mail | index | archive | help
[It's late, please excuse me for some bad english] We should keep in mind that we have a manpower problem. It is not the actual hours/month that the doc team spends, but the fact that too few people have the full idea how things work together. This is not going to change. We need an easy solution that does not rely one someone keeping details in mind. It should be as intuitive as possible. Let's look over the three ways to adress the problem again: 1) We require mirrors to have all WWW-building tools up-to-date. 2) We build in www/ with relative program targets like ../../src/usr.bin/sgmlfmt/sgmlfmt. We perform a 'make', but no 'make install' in these program directories. If the program needs additional steps after 'make all' to be operational in this directory, an additional target 'make for-www' can be added, which sets things up, but does not copy anything out of the src/ build directory. 3) We build all the tools from src/ and install them to a non-default target where only the WWW build process will find and use them. Every such tool then has two install targets, 'make install' will install to where the FreeBSD release expects it and 'make www-install' will install to wherever the WWW tools tree is. (Or two copies of the program are in the CVS tree, see below). I think that 1) is out of question and that 2) is better than 3). It is easier, the mirror maintainer will not have to set up a place where to install the tools to, he will not have to tell the build process where this place is. Using this place will mean that we need to have Makefiles in www/ that get their tools from a location only known at run time, maybe using the $PATH variable. In comparision, the full relative build of 2) uses a hardcoded location ../../src/some/thing. I think people are much more likely to understand what 2) does than what 3) does. The Makefile will simply be easier and it is obvious what it does, while the solution with the different tools tree will have to maintain a moving target. 2) is much easier to maintain once the architects of the build process lost interest :-) The advantage of 2) becomes evern bigger when we take into account that the number of tools - namly languages - that are using during the build procress might include a complete zoo of solutions how to tell them what library to use if not in /usr/local. Setting this up is much more easy using relative - but fixed for every machine - location than to parametrsize on a absolute directory that will vary from mirror to mirror. 2) und 3) come in two variations a) For all programs that are needed for the WWW build process we have copies in src/ and www/ so the src/ is never needed. That way, people that modify these tools don't have to care whether they affect the general FreeBSD release. b) We keep the tools in src/. We have to trust those who work on WWW and make modifications that they don't break the src/ tree. In both cases will tools that are *only* for www and never for a release be added to www/ In pratice, I think that b) should be done. With the exception of perl, I think there are not many tools where www/ and the general release will conflict. I think it should be a much bigger concern for us to keep the source tree in a maintainable manner and that having two versions of a program in different places in the CVS tree should be avoided. > 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. I doubt that will be case for much more than perl. For any other tool I can think of, either WWW or the normal FreeBSD system can use whatever that other needs. The disadvantages of maintaining two copies are far greater, IMHO. > 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. I think you didn't really understand what I'm proposing. I want a WWW mirror to check out the whole www/ directory of the CVS tree and parts of src/ (using a CVS module, this is trivial). The WWW build process then uses the programs it relies on from the src/ directory, i.e. ../../src/usr.bin/smglfmt/sgmlfmt or ../../src/share/mk/whtever.mk. Programs from this src. tree are not installed to the base system. That way, we transport versions of the tools along with the www pages and keep them in sync, but we don;t touch a user's machine. > 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. I agree that perl is a problem, but perl5 is required anyway for some cgi stuff (I think), we could require that mirrors have /usr/local/bin/perl == perl5. Have to think over it. > > 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. Yes, but this build environment needs to be set up. writeable Space must be there, in an absolutly addressed location and since it can vary (we can't push mirros to use a fixed location), you need to have a build rocedure that will accept some way to tell it where to find the stuff. In my solution, the tool location is always fixed and you don't need an extra place besides the CVS checkout tree and the target for the built www pages. > 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). OK, but I imagine that the usual way to set up a mirror i to run the build process on the same machine that is the http server. We need this for example to take care of local specialities like CGIs to run locally and local additions. > 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 tools need to be built somehow, but I think they don't need to be installed anywhere. > > 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. I didn't talk about relative links in WWW pages, only relative locations of tools during the build process. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@wavehh.hanse.de> http://cracauer.cons.org Fax +49 40 522 85 36
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9704142319.AA25408>