[Buildroot] Hiding non-buildable packages

[Bernhard Fischer <rep.dot.nop@gmail.com>]

On Wed, Aug 22, 2007 at 10:44:38PM +0200, Yann E. MORIN wrote:
>Ulf, Bernhard and All,
>
>On Wednesday 22 August 2007 22:24, Ulf Samuelsson wrote:
>> If people starting using buildroot had this help, then they could
>> spend their time first building a working filesystem, and then select
>> a specific, non-working package, to debug.
>
>For what it's worth, here's my point of view.
>
>When _I_ start from scratch on something I have no previous knowledge of, then
>I tend to build the smallest set I can. In this case, I'd disable everything in
>buildroot, save building the toolchain.
>
>Once I get that first step right, I start by adding things bit after bit. For
>buildroot, BusyBox looks the most basic thing that can be added to a bare rootfs.
>
>Again, once this is working, I would get more comfortable to try other things,
>such as adding other tools, for example wireless tools (supposing I'd need that).
>
>And so on till I get something that doesn't build, which I'd try to debug, submit
>a patch or workaround, and resort to asking help if I can't solve it on my own.
>
>What I'm trying to say is that someone starting with buildroot and expecting
>to be able to build every and all packages shouldn't be surprised if something
>goes amiss.
>
>The rule is: divide and rule. Take pieces bit after bit while it works, and

divide et impera, nod.

>you get a 'stable' basis to try a new feature. Bash this new feature until it
>works, and start again.
>
>On a personal experience, I have background that tells me what package to add
>or not in a config. This is becaise I've had previous experience telling me
>that such or such option is valis in such or such circumstances. Those are far
>too complex to express in terms of Kconfig, I'm afraid.
>
>> If it is known not to build, it is good to communicate this to others.
>
>But it might build in some cases which are not your daily config.

Normal dependencies that are hardware dependant are ok to add. Anything
else is not, since it just tried to work around bugs, which is
inacceptable.
>
>My 2 euro-cents.

It's not that we have a feature-rich and demanding default
configuration.. The default (including about all of busybox since that's
what's supposed to be tested alone uclibc by br) should build and of
course work correctly just fine, from my POV. Y(not Yann's)MMV