[Buildroot] How handle broken or partly broken packages in the distribution

Thiago A. Corrêa thiago.correa at gmail.com
Fri Jan 23 21:17:32 UTC 2009

On Fri, Jan 23, 2009 at 3:46 PM, Ulf Samuelsson
<ulf.samuelsson at atmel.com> wrote:
> Why on earth do you want to enable a thing which NEVER will work?
> If you want to update the package so it works,
> then you can do that in the trunk which should not
> have these limitations turned on by default

As I said, just remove the package from defconfig.
If we start disabling stuff just because of some minor build problem,
the chances that it will be fixed and enabled again are slim. How do
you differentiate things that are just minor corrections from things
that doesn't make sense at all to be enabled in that platform?

We would of course want to disable PCI Utils in AVR32 since there is
no PCI bus there. But not linux-fusion stuff that doesn't build right
now but it did a while back.

Usually a release is a trunk revision at some point. Going thru
several packages disabling them just for releases isn't much

> The distibution, on the other hand, should be easy to use
> and should IMO protect users against wasting their time.

They can read the help message for that. A common pattern for users is
to build the default config first, and that we should make sure to
have working.

Kind Regards,
    Thiago A. Correa

More information about the buildroot mailing list