Re: linux kernel config converter

[Jeff Garzik <jgarzik@mandrakesoft.com>]

Jason Lunz wrote:
> 
> Jeff Garzik wrote:
> > David Lang wrote:
> >> I'll argue that _not_ doing this violated the principle of lease surprise,
> >> if you turn a feature on and immediatly back off why should anything in
> >> your config be any different then it was before you turned it on?
> >
> > Imagine this case:
> >
> > make xconfig # select CONFIG_USB_HID, which auto-selects CONFIG_INPUT
> > { time passes }
> > make xconfig # de-select CONFIG_USB_HID
> >
> > On the second 'make xconfig', should CONFIG_INPUT be automatically
> > de-selected?  No.  Because that is making the assumption that the person
> > does not want to continue to make the input API available.
> 
> It depends. When CONFIG_USB_HID auto-selected CONFIG_INPUT, did the user
> know about it? Or did it just happen automagically behind the scenes? If
> it was turned on silently, and the subsequent de-select of
> CONFIG_USB_HID silently left CONFIG_INPUT turned on, I'd say that
> violates least-surprise.
> 
> On the other hand, if turning on CONFIG_USB_HID then prompts "to do
> that, I also have to turn on CONFIG_INPUT", i suppose it's ok to leave
> CONFIG_INPUT turned on later.

You do have a point, because there is a small change that a
configuration symbol can be auto-enabled without prompting.

This is more just standard Unix pragmatism, treating auto-remove
operations with far more caution than auto-enable operations, precisely
for cases like the example one above.  Only when one has pretty much
complete control of environment do you want to make the assumption that
a 'remove' op is the perfect complement of the 'add' op.

	Jeff


-- 
Jeff Garzik      | "Why is it that attractive girls like you
Building 1024    |  always seem to have a boyfriend?"
MandrakeSoft     | "Because I'm a nympho that owns a brewery?"
                 |             - BBC TV show "Coupling"