From: Pavel Roskin <proski@gnu.org>
To: buildroot@busybox.net
Subject: [Buildroot] new DHCP version and make error
Date: Tue, 28 Nov 2006 20:43:48 -0500 [thread overview]
Message-ID: <1164764628.4016.64.camel@dv> (raw)
In-Reply-To: <49328.206.190.75.8.1164762791.squirrel@picard.linux.it>
On Wed, 2006-11-29 at 02:13 +0100, Rafael A Barrero wrote:
> Hi;
>
> I agree that buildroot should take step forward in this direction. A
> "distribution building system" should be able to maintain a stable process
> for creating these distributions, no?
I was only talking about availability of the packages. Stability has
other aspects.
Some packages may be incompatible with the latest compilers or with
certain targets. For example, gcc 4.1.1 won't compile acpid without a
minor patch (and the complication is that acpid.mk doesn't know how to
apply). Adding support for new compilers is likely to affect some
packages.
Also, uClibc snapshots have options that affect some of the packages.
For instance, unselecting fnmatch() support would break Busybox. The
build system should incorporate this knowledge an help users make the
best choices.
Buildroot offers diverse options and supports a magnitude of packages.
It's almost unavoidable that something would be broken. I think the
priority should be to improve the infrastructure to reduce brokenness
and to exclude known bad configurations. That includes adding a
testsuite.
Releases could have more rigid constraints than the development code.
In particular, use of snapshots of Busybox and uClibc should be strongly
discouraged in the releases.
Maybe we could have an option to disallow selection of snapshots,
something like CONFIG_EXPERIMENTAL in Linux?
> I for example have just begun to work with buildroot and I'm coming across
> missing software distributions or software distributions that simply do
> not compile.
>
> For example - gettext-0.14.6 does not compile... what do you guys suggest?
> Do I remove it from my list? Use an alternate version? Fix the bug?
It depends on your priorities. The best approach for everybody would be
to have the problem fixed, but it may take more of your time.
> Does anyone have a known-good list somewhere (for x86 targets)? What
> versions allow buildroot to compile cleanly? Completely?
I don't have such list. If the problem is just with the packages, you
can enable all of them and then disable those that don't compile. That
would give you the known-good list for your compiler.
> I certainly don't mind pitching a hand... I've got some spare systems and
> could put together a quick test matrix. Thoughts?
Posting the list of broken packages would be a great start.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2006-11-29 1:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-28 20:27 [Buildroot] new DHCP version and make error Rafael A Barrero
2006-11-28 21:38 ` Rafael A Barrero
2006-11-28 22:28 ` Pavel Roskin
2006-11-28 22:37 ` Marc Lindahl
2006-11-28 23:59 ` Pavel Roskin
2006-11-29 1:13 ` Rafael A Barrero
2006-11-29 1:43 ` Pavel Roskin [this message]
2006-11-29 8:52 ` Bernhard Fischer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1164764628.4016.64.camel@dv \
--to=proski@gnu.org \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox