httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Date Fri, 21 May 2004 00:49:27 GMT
Geoffrey Young wrote:
>>>so you're arguing that we should write out the sticky files, even if the
>>>user doesn't ever want them interfering?
>>I'm not arguing at all. It's just when
>>APACHE_TEST_NO_STICKY_PREFERENCES=1 and no arguments passed, the logic
>>is broken. The program gets into a loop it can't break out of.
> an endless loop?  hmm, I hadn't seen that.  _something_ definitely needs to
> be fixed, then.

the endless loop in the following way: you don't provide args and you tell the 
program not to use the previous config, so it starts interactive config, you 
answer the questions, it tries to save them, but 
APACHE_TEST_NO_STICKY_PREFERENCES=1 prevents it from saving them. the program 
restarts, and goes again into the same loop.

>>suggested a fix, if you don't like it, please suggest a different one.
> ok
>>For example do not run interactive config if
>>APACHE_TEST_NO_STICKY_PREFERENCES=1. But it's a pity, since we could
>>suggest users this technique to override older saved config (in addition
>>to -save).
> well, I think I'd like to see some more intelligence with the sticky
> preferences option.  for instance, I'd like to see a -remove option that
> removed all hints of sticky preferences, to avoid exactly the error-prone
> manual removal you mentioned in your last message.

I think you don't want it to be removed, you want it to be ignored. If it 
doesn't get on your way, why should you care if it's there or not.

If it's removed you have to configure it again, which is annoying. But sure, 
if you want to code -remove option that's fine. perhaps change -save to extend 
to -custom_config=[save|remove].

> and you have a valid point - is there any way to override existing sticky
> preferences?  IIRC that was my main problem with all of this, that the
> sticky preferences were too sticky for my needs.  rather than abolish them
> altogether, it would be nice to have an -interactive option to force
> interactive configuration again (which would not be saved unless -save was
> specified).

That's how I coded it. Please see the documented logic. It's quite possible 
that I didn't take into account some things that you do, but it perfectly 
works for all my setups.

> speaking of -save, I can't recall if that is the default, but if it is I
> wonder if it should be.  

it's the default if no config already saved. -save is really -override.

> it might not be easier on end users to save the
> first time, but it might help them in the long run if things were not saved
> until explicitly  given -save.  what if the first time they run A-T it's
> against a development apache version?  it's not exactly intuitive how to
> un-stick yourself, so being sticky by default (rather than on demand) might
> end up causing trouble down the line.

That's not the case with most of users. Most users will install mp2 which will 
  save the config for them anyway (regardless of A-T), then they will run 
other modules against that. If the upgrade their server and A-T can't find it 
in the same location it has saved, it'll ignore that config.

As I said above -remove is a good idea, but I doubt it can be easily 
implemented correctly if at all. Unless you make it a separate path (i.e. 
remove and quit) you are complicating the already complex logic even more 
complex. That's because the custom config may get loaded from Makefile.PL or 
from the test suite itself. In fact that's exactly where it won't work - if 
you call -remove and it deletes system-wide file, you will still have it 
locally. Moreover it may require root perms. And you may have hidden @INCs 
which may kick in later...

I'd rather see a good test case of yours where things don't work as expected 
(i.e. custom config gets on the way of the explicit options) and get that fixed.

That's all said, I'm not disagreeing that we need an intuitive way to fix any 
stale custom configs. May be option -save should have a bit of overloading in 
it: ignore any custom configs, use the explicit options, passed via env vars, 
command line args or interactive config, and save them overriding the old 
configs. Which is similar to my idea of NO_READ in the previous post.

> just some ideas.

Yeah, but we still have a problem to solve.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message