Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 6276 invoked by uid 6000); 11 May 1999 15:21:31 -0000 Received: (qmail 6262 invoked from network); 11 May 1999 15:21:28 -0000 Received: from main.aquanet.co.il (192.117.240.10) by taz.hyperreal.org with SMTP; 11 May 1999 15:21:28 -0000 Received: from elmar.co.il (ip3.elmar.co.il [192.117.252.19]) by main.aquanet.co.il (8.8.7/8.8.7) with ESMTP id QAA19870 for ; Tue, 11 May 1999 16:58:16 +0300 Message-ID: <37384308.2C31561E@elmar.co.il> Date: Tue, 11 May 1999 17:47:36 +0300 From: Eli Marmor Organization: El-Mar Software Ltd. X-Mailer: Mozilla 4.08 [Hebrew Support by elmar.co.il (X11; I; SunOS 5.5 i86pc) MIME-Version: 1.0 To: new-httpd@apache.org Subject: Re: Annoying Installation Problem and a Possible Elegant Solution References: <37382B87.659381A5@elmar.co.il> <19990511082151.A2549@holly.dyndns.org> Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Chris Costello wrote: > > On Tue, May 11, 1999, Eli Marmor wrote: > > And think about the maintainers of pre-built packages of Apache: > > Currently, all of them state that "sorry, but the current version > > must be installed under the following directory...". > > The way I understand it, the only way it's possible for them > to make it so that it only works in a specific directory is to > patch Apache to ignore a lot of httpd.conf, because you can set > various directives to change where things go - ServerRoot, > LockFile, DocumentRoot, etc. under a normal, unpatched > distribution. Any of us makes Apache "so that it only works in a specific directory". If you don't believe, try "./configure --prefix=path1" etc., then "make" and "make install", then "mv path1 path2", and then "path2/bin/apachectl anything-you-want". Of course, you can ignore apachectl, but if nobody needs apachectl then why is it there. Moreover, this problem is not specific to apachectl. Try to bypass it by "httpd -f", and you'll find that other things can't be found, because the config files are not updated. Again, you can ignore "make install" and claim that smart people edit the config files, but if nobody needs "make install", then why is it there. If the normal way is to put paths manually into httpd.conf, then why "make install" does it? I can continue with many other examples, but I think my point is understood: Major parts of Apache does not meet the minimal demand to move Apache between directories, environments, etc., unless a re-compilation is done. If you don't think that these parts are needed, then remove them from the distribution, and we will end up with a small and compact Apache. But I believe that these parts ARE important, so please read again my original message, and re-consider it seriously. I even volunteer to help in coding it (I already did it manually by sed's etc.), at least in days that I work less than 24 hours. And Rasmus wrote: > Well, if you are going to move an Apache tree, it seems logical that you > would want to fiddle with the paths in httpd.conf yourself as well. Do > you really see a need for an automated way of doing this? There IS already an automated way. It is called "make install", and it sets your config files, apachectl, and many other files, to have the correct values, according to your "configure" flags. If you assume that people should edit their files manually, then why is "make install" there? > For people who > don't want to change the paths in their httpd.conf file, they can always > do a clean re-install with a different prefix path. Unless they don't have a compiler under this machine (Apache was compiled under another machine). Or they don't have the source-code /source-tree/etc. (they got it as a pre-compiled binary). Or they are newbies who don't know how to compile Apache. Or a lot of other possibilities. In short, there must be a way to move Apache without re-compiling it. And to have a "apache_for_unix2000.tar.gz", which can be extracted anywhere by "gzip | tar" and fixed by "install.sh" (the script I proposed, to fix the paths and other configuration variables). -- Eli Marmor