httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: daedalus is running httpd-2.0.pre40
Date Tue, 23 Jul 2002 14:15:43 GMT

> From: gregames [mailto:gregames] On Behalf Of Greg Ames
> Ryan Bloom wrote:
> 
> >   You are working around a problem in your script in the Apache
> > upgrade step.
> 
> no sir.  It would have been a piece of cake to change my perl script
to
> insure
> that conf/ has enough stuff so the server can start.  But I couldn't
take
> the
> easy way out with a clear conscience because other people are likely
to
> get
> burned in a similar manner.

Come off it.  That is insane.  You have a broken script, fix it.  Nobody
else will get burned this way, as proof, this is how 1.3 has worked for
years, and there were never any complaints.  Anybody who has an existing
configuration who wants to copy that config to a new server MUST copy
all of the config files.  You script didn't.  That is broken.  Period,
end of story.

> >  Now, on EVERY production machine I have, I will always have
> > *-std.conf files.
> 
> Another way to word this is that whenever you do a make install your
> standard
> configuration files are updated to match the current code.

Why would I possibly want that?  The -std files have no relationship to
my server.  None.  I may have started with them years ago, but my
current config doesn't look anything like them.

> >  Why is that a good thing?????
> 
> Most of the time I use daedalus's config files or something that
closely
> resembles them.  Those are complex, but don't include every possible
> combination
> of config directives (thank goodness).  Every once in a while I need
to
> drop
> back to a simpler config to do benchmarking, or something with new
config

If you are doing benchmarking on deadalus, then we have issues.  Since
we are talking about your automation scripts on daedalus that is the
only thing you could mean, right?

> features to work on a problem for instance.  It's nice to be able to
grab
> one of
> the -std.conf files, make minimal/no changes, and have a working
server
> with
> guaranteed current config directives in short order.

Fine, so grab one, but DON'T put it in MY production conf/ directory
please.  I don't care where you keep a copy of those files, but they
don't belong in my product conf/ directory.

> If you read this whole thread, you'll see that I'm not the only one
who
> likes
> having current -std.conf files available.  They worked this way for
ages.
> I
> don't recall seeing any complaints about this behavior until
yesterday.

I don't care how many people like it, it is wrong (besides, if that
argument help any water at all, I could point how that in the last few
days, there have been at least three users disagreeing with the current
code).  It has only worked this way since 2.0, and we didn't spend a
whole lot of time on the install phases until recently.  As for
complaints.  If there hadn't been at least one (mine!), I wouldn't have
changed the install-conf target to match 1.3 weeks ago.

Ryan


Mime
View raw message