httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bishop <>
Subject (6397) Re: [Fwd: Call for issues: [STATUS] (apache-1.3)] (fwd)
Date Fri, 29 Sep 2000 14:31:13 GMT

Manoj Kasichainula wrote:
> On Thu, Sep 28, 2000 at 10:13:50AM -0400, Jim Jagielski wrote:
> > > jim!
> > >
> > > PR6397 ?  Please?
> > >
> > > Actually, I got the sum total of NO interest in it, although freshmeat
> > > thinks I had about 500 people or so pick it up from the page.
> > >
> > >
> At work, we just use a shell script that cats all the files in a
> directory together into httpd.conf. Why not just do that?

That was actually my first thought, too:  It ain't broke, so why'm I
fixing it?

The response I got was related to reloading the server via a HUP command
:  while the perfectionists in favour of the simple build-and-start
method will say that vulgar acts like sending HUPs to reload should just
not then be allowed, the eventual client in question is a perfectionist
that believe that scripting is bad (m'kay) and the program should know
how to do this on a simple signal.

(The discussion here about a --foreground-no-debug option are bad

Then, there's the argument about a repository for module (de)activation
clips.  Toss it into a [...]/httpd.d/section1GlobalEnv/04modules/1add/
directory for adding, and no need to patch a config file that may have
been altered from the cut distro.  The pre-launch script is now running
find(1) to gather the files, avoiding any symlinks to directories while
including regular symlinks and stuff that promotes headaches in find(1).

Then, what about the Include config statement?  There are those of us
who like the idea of tuning the module list without hosing the
httpd.conf, and so may use an included directory.  The patch has its
roots in an IncludeDir instruction discussion.  In such a case, an
included dir of statements fulfills the desire for versatility without
falling completely into the fragmented-cfg-file mess.

All of the reasons for running the patch can be solved via a pre-launch
shell script, I'm sure.  The beauty of Unix is that we are given a
choice in what we think the most elegant solution to a problem is in a
given environment.  Imho, this is just an enabler for yet another means
of solving the same problem, in a way that doesn't tax us too harsh if
we completely choose to ignore it and use your method.  Heck, the whole
thing's backward compatible, from what I can see, yet another factor in
the method.

All in all, it convinced me, and the rest you know.

 - bishop

View raw message