Re: [patch, -git] media/video/sound build fix, TEA5761/TEA5767

[Ingo Molnar <mingo@elte.hu>]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> [OT to the actual problem]
> 
> I have envisioned something like a "requires tag" that would list what 
> a config symbols needs.
> 
> Like in this case it would have been:
> 
> 	requires V4L
> 
> This should in the frontends then if the user selects a symbol where 
> the 'requires' are not satisfied with a window listing the menuentries 
> for the symbol that the user needs to enable to satisfy what the 
> original symbol requires.
> 
> This is the only way to do this in a way so the user is actually aware 
> that enabling a webcam also enables USB. Or at least this is my best 
> suggestion.

but auto-selecting USB is the obvious thing that most users expect...

I.e. they expect a static hierarchy of 'every component' that exists and 
that can be selected. [yes there are complications like multiple-choice, 
but that's the minority]

Users want to browse the hierarchy and pick their things - and _at most_ 
the tool should warn if there's side side-effects of a selection - users 
will likely not mind that enabling a webcam also enables USB (in the 
overwhelming majority of the cases they couldnt care less about that).

But otherwise it should all be automatic.

And i dont even think there should be any additional Kconfig 
complication. Kconfig should be made _simpler_, not more complex. 
Maintainers list dependencies and that's it. No "select" needed at all! 
The stuff that needs to be selected automatically derives from the 
"depends on" tree that we code.

in fact even dependencies between modules of source code should be 
auto-discovered most of the time.

The symbol dependency tree from an allyesconfig kernel could give a 99% 
accurate map of all the dependencies that exist in the code. Why burden 
humans with that? We've got better things to do than to figure out 
dependencies between source code as the dependencies can be totally 
non-obvious.

Humans might want to _optimize_ the dependencies after the fact and get 
rid of unnecessary dependencies (so that the kernel gets smaller, etc.), 
but there should be no correctness ramifications of it visible to 
developers or users.

So the whole thing is being thought about exactly upside down i believe.

	Ingo