Messages in this thread | | | Date | Thu, 1 May 2008 03:29:22 +0200 | From | Ingo Molnar <> | Subject | Re: [patch, -git] input: CONFIG_INPUT_APANEL build fix |
| |
* Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> On Thu, May 01, 2008 at 12:38:29AM +0200, Ingo Molnar wrote: > > > > * Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > > > > > > i'm not suggesting this is your fault in any way - but nevertheless > > > > many other subsystems have to deal with the same Kconfig issues and > > > > they manage to limp along. > > > > > > I believe I see a steady stream of breakage for leds dependencies from > > > all subsystems. > > > > they limp along by adding "depends on NEW_LEDS". 99% of the users > > will use some pre-cooked distro kernel where all these options are > > turned on, so the flattening and coupling of the dependencies is not > > a real issue in practice. > > You still did not answer to the main question - do you think we should > revert the commit that actually introduced breakage in the sense that > anything depending on LEDS_CLASS should also add NEW_LEDS dependancy? > That will take care of the problem (as far as LEDs are concerned) for > _all_ subsystems and drivers at once.
do you mean this one:
| commit 66242f7ec531953fbc2f4040c5ffe1f1ffe6c5c9 | Author: Jan Engelhardt <jengelh@gmx.de> | Date: Thu May 10 10:44:11 2007 +0100 | | leds: Use menuconfig objects II - LED | | Change Kconfig objects from "menu, config" into "menuconfig" so | that the user can disable the whole feature without having to | enter the menu first.
?
that split option definitely looks a bit weird, and the sprinkling of LEDS_CLASS+NEW_LEDS dependencies to all affected drivers feels broken as well. I'm all for fixing it right and can test any patch.
Ingo
| |