> 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
