To: new-httpd@apache.org
Subject: Re: [PATCH] Configuration (4/4): TARGET name
References: <Pine.BSF.3.95q.981201104714.1582m-100000@valis.worldgate.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Randy Terbush <randy@Covalent.NET>
Date: 01 Dec 1998 12:09:39 -0600
In-Reply-To: Marc Slemko's message of "Tue, 1 Dec 1998 10:48:34 -0700 (MST)"
Message-ID: <x7emqjohss.fsf@montana.covalent.net>
Lines: 42
Sender: new-httpd-owner@apache.org
Precedence: bulk
Reply-To: new-httpd@apache.org

Marc Slemko <marcs@worldgate.com> writes:
> On Tue, 1 Dec 1998, Ralf S. Engelschall wrote:
> 
> > 
> > Configuration (4/4): TARGET name [config-target]
> > ------------------------------------------------
> > 
> > This patch tries to complete the TARGET-related part of Randys recently posted
> > patch (which addressed only a few issues). The idea is to make the TARGET
> > variable more generic and wider applicable so it can be used to change the
> > installation name from "httpd" to "apache", "httpsd" or whatever. The default
> > is still "httpd", of course. But when you say TARGET=apache you get
> 
> Is it really worth it?
> 
> Changing the names of all sorts of things based on user or packager 
> whim is a precursor to hell.
> 
> I'm just not sure where the need for this is coming from and would 
> really prefer trying to avoid tacking more and more stuff over top
> of the current framework unless necessary.

It's needed from the standpoint that many (most?) users using Apache
run several servers with different compiled configurations. It is a
common problem where the config file, binary etc. is confused with
another and the fact that Apache automagically reads in srm.conf and
access.conf if they exist makes it even more fragile. 

If a user is running a couple of different binaries and suddenly
decides to put a couple of things in his/her srm.conf file, they won't 
realize that these changes have just been applied to all servers
starting from that configuration directory. An error message
identifying what server is having the problem is yet another clue as
to where to look. I don't see how either of these changes can be
argued against.

The srm.conf and access.conf files have not been removed from the
distribution directory. My change just prevents them from being
stuck in the install area and continuing to propigate this confusion.